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?

Perhaps I have misread your comments at https://issues.guix.gnu.org/71581#13.
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