Hello Jelle,
I've just sent a patch series (https://issues.guix.gnu.org/74187)
bumping our node-lts package to 20.18.0. This would be a first step to
bumping it to 22.X.Y, after which I think it should be fairly easy to
create and maintain an up-to-date node-current package.
Thank you for your patches. This will also be a good exercise for me to
read package definitions for `node-lts`.
AFAICT node@10 is the last version that can still be used to properly
bootstrap the llhttp packages without itself depending on llhttp; We use
esbuild to compile all the TypeScript to JS, and subsequently use
node@10 to run this JS which in turn generates the C code that is used
to build llhttp (and subsequently, Node versions after 10).
If this all sounds like an example of the XY problem, that's because it
is :). What we really need is _some_ way to (re)generate the C code that
is a part of llhttp. If there is some other (minimalist) JS runtime that
could do this, that would be a major improvement over what we currently
do.
I had this in my head for quite a while, and maybe I could be wrong here,
but could we use anything like QuickJS, tinyJS, etc? Since they do not
support NPM, I highly doubt if they can be used as a substitute.
WDYM exactly?
I was under the impression that llhttp may have some TypeScript/JavaScript/C
code meddling with building `node-lts`.
Are there any things you've already started working on? I'd love to see
what we can do to make this happen.
Unfortunately, no. Working with compilers and interpreters is beyond my
expertise. I have just recently started to delve into system programming
seriously.
I don't use any of the non-npm options, but could you check if they can
be installed using (e.g.) `npm install -g --prefix="$HOME/.local` after
applying the patch series that bumps node to v20?
Not really relevant for guix proper, but earlier this year I pushed the
npm-binary importer that could perhaps be used to package some of
{yarn,pnpm,lerna} in a channel or local guix.scm.
Personally, I liked using `pnpm`, but I guess that this is not that serious of
an issue. I think I'll try the command you've shared.
I was also of the opinion that we may remove `http_parser`, but it looks like
there are several dependencies - some have moved over to `llhttp`, but some
packages, like `psi` and `psi-plus` are still dependent on `qhttp`, which in turn
depends on `http_parser`.
With respect to removing internal source dependencies, do you think it would be
possible to remove dependency for `simdutf` and `uvwasi`? I think I've written
package definitions for both of them earlier - maybe I could rewrite them again, and
try adding them as inputs this time.
Regards,
Ashvith