wip-node-14 branch

[Jelle Licht <jlicht@fsfe.org>]

Hey Guix!

Depending on whom you ask, I come with what I see as good news! I just
pushed a series of patches with the long-term goal of getting the
Node.js situation in guix unstuck. You may find it on the `wip-node-14'
branch on on Savannah.

First things first: most of the hard work has been done by others. I'd
like to specifically thank Timothy Sample for their
`other-node-build-system' and Ryan Prior for getting `esbuild' packaged
and telling me about it. A shout out goes to Giacomo Leidi for making me
grumpy enough with the existing node-build-system to finally sit down
and fix this. I added Timothy as a Co-author on the first commit, so I
hope that is Good Enough for the copyright situation.

The branch contains the following changes:

- A revised `node-build-system', shelling out to `npm' for pretty much all
  phases of building a package. This also solves some inconsistencies
  our way of installing node packages lead to before [0]. It makes the
  current npm packages a bit more verbose, but if we ever end up with
  'properly' built npm packages, they should be easy to write.

- For now, I took the most recent Node.js package we had available that
  we could still build from source, and arbitrarily made an alias for it
  dubbed `node-bootstrap'.

- I used `esbuild' and some good old fashioned distro-packager moxie to
  bend the packages we need to run `llhttp's TypeScript and generate C
  files. I have also verified that the generated C files are identical
  to what is distributed upstream.

- I added a libuv-node package that tracks libuv upstream at a pretty
  fast pace. Help wanted on how/where/if we should manage this.

- ... and then I packaged Node.js version 14.14, which should last us
  for a good couple of years :-).


Some open issues/challenges:
- We used to patch out references to bundled dependencies in Node.js; this
  is no longer easily possible in some cases, although I have verified
  that the `--shared-XXX' flags do work; in practice this just means we
  waste some space in storing the sources for Node.js 14.

- There is a wrapper in use by Node.js for libuv called uvwasi; Once [1]
  is closed, we should look into packaging and subsequently unbundling
  this.

- Currently it is not possible to build a shared-library of `llhttp'[2]:
  I currently worked around this by generated both the sources and
  static library of `llhttp', and copying over our generated
  `llhttp.{c,h}' into the Node.js sourcetree. It works, but it ain't
  pretty. Once we can build llhttp as a shared library and Node.js
  supports a `--shared-llhttp' configure flag, we should do that.

- There are two (disabled) tests with a "TODO" comment above them. As a
  result of me not being clever enough and my laptop not being fast
  enough to compensate, I have not been able to figure why these tests
  fail (and if that is a problem in practice).

- There is _a lot_ of almost-duplication going on between our `node' and
  `node-14.14' packages; I don't like it whatsoever.

As a small extra, I have also worked on getting Timothy Sample's
'binary' npm importer to work with the contemporary guix import and
guile-json APIs; I'd like some insight into whether this binary importer
could still hold some value for inclusion in guix proper[3]. I could
still add this code to the branch as well if there is interest.

I won't be able to commit significant chunks of time on my end in the
upcoming month, but I've learned that it makes sense to share once you
have something worth sharing, instead of when you think it's
done. Reviews, tests and improvements very much welcome! I don't think
it makes sense to still target the upcoming release for all of this fun
stuff to be merged into master, but if somebody want to pick up the
slack and champion that cause; go right ahead!

Thanks!

 - Jelle

[0]: http://issues.guix.gnu.org/41219
[1]: https://github.com/nodejs/node/issues/35339
[2]: https://github.com/nodejs/llhttp/issues/52
[3]: http://logs.guix.gnu.org/guix/2020-10-23.log#123831