[bug#71581] [PATCH 11/11] gnu: Remove node-bootstrap.

[bug#71581] [PATCH 11/11] gnu: Remove node-bootstrap.

[Ashvith Shetty]

* gnu/packages/node.scm (node-bootstrap): Delete variable.

Change-Id: I634b79ab744597a2bf141d644db680b043f07f09
---
 gnu/packages/node.scm | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/gnu/packages/node.scm b/gnu/packages/node.scm
index b6e3ccc00c..d560faa042 100644
--- a/gnu/packages/node.scm
+++ b/gnu/packages/node.scm
@@ -329,11 +329,6 @@ (define-public node
                   (timeout . 21600)          ;6h
                   (cpe-name . "node.js")))))
 
-;; This should be the latest version of node that still builds without
-;; depending on llhttp.
-(define-public node-bootstrap
-  (hidden-package node))
-
 (define-public node-lts
   (package
     (inherit node)
-- 
2.45.1

[bug#71581] [PATCH 11/11] gnu: Remove node-bootstrap.

[Jelle Licht]

Hi Ashvith,

Thank you for working on Node.js related things in guix.

My apologies for not looking into your set of contributions earlier, I
have an longer train ride coming up where I can set aside some time for
proper reviews.

Ashvith Shetty <ashvithshetty10@gmail.com> writes:

> * gnu/packages/node.scm (node-bootstrap): Delete variable.

It seems there has been a misunderstanding (not on your side!) about the
construction of the llhttp package.

It is a bunch of javascript that generates code in C, which can
subsequently be compiled by any C compiler. This means that the llhttp
package that is currently included in guix does not meet our packaging
criteria, and should be patched and/or removed. I'll send a bug report
for this separate issue later.

(IMHO this will boil down to it being built like llhttp-bootstrap, but
perhaps using the node package instead of the node-lts package. Either
way, the node-bootstrap and llhttp-bootstrap packages would still be
needed)

Provided I didn't misread the situation, this makes your patches require
rework; perhaps we could discuss a way forward that respects your time
as much as possible. It might make sense to jump up to the latest
Node.js LTS version (20.x.y) instead of the 18 series. I even think we
could patch more modern llhttp versions so that we could still build
them with Node.js 14 (node-bootstrap), in which case we could move
towards the Node.js 22 series.

Kind regards,
Jelle

[bug#71581] [PATCH 11/11] gnu: Remove node-bootstrap.

[Ashvith Shetty]

Hello,
I'm not really an expert in build, so I'd really appreciate someone
guiding me with this. Also unfortunately, I cannot diagnose NodeJS
properly, because building it takes almost more than a day on my
potato PC, only for the  build to fail because some parallel tests
don't work on Guix. So far, the minor bump to 18.20.0 has worked fine
for me, and I was planning to leave it to the last version, so that
anyone else looking for NodeJS 18 could use inferiors to package their
project. I grew tired of having to do this every time, so right now,
I'm packing all the dependencies - `simdutf`, `uvwasi`, `ngtcp2`,
while also removing dependencies in NodeJS that also exist in Guix,
like for example, sqlite.

One advantage I see to this is that the builds will be cached for a
particular dependency, and also shared between them - at least in my
idea, this would be great for Electron, Chromium forks, Node and also
Deno.

Right now, there's a few roadblocks:
- V8 shared library support was removed around 2015, meaning that I'd
have to use a patch to get around this.
- Support for shared libraries for tinier dependencies like simdutf,
uvwasi and ada does not exist in the file `configure.py`
- There's no way to build a project that uses bazel, because it does
not exist on Guix at the moment.

The first two issues can probably be dealt with, using patches over
nodejs. However, I'm pretty sure working on the third one would
require working on adding bazel as a build system and at least for the
time being, we will have to use internal v8. For JS-based dependencies
like acorn, acorn-walk, undici, etc, is it not possible to use
txiki.js instead? I was thinking of eliminating all node-based
bootstraps, using this tiny JS runtime to build main dependencies.
That, or perhaps, a node-minimal package that is free of extra,
unneeded stuff.

Regards,
Ashvith