Option to have a shared V8 library?

[Ashvith10]

What is the problem this feature will solve?

In distros like NixOS and GuixSD, building NodeJS from scratch is a heavy computation. Building V8 seperately for NodeJS is not only computationally heavy, but it also makes caching the good parts of the library impossible for a simple failed test. It is painful having to wait for a day to have a package build, only for the tests to fail for the package maintainer to disable or patch them one by one per build.

What is the feature you are proposing to solve the problem?

With V8 as a shared library, it would be possible to not only cache the dependency in a functional package manager, but also use it with other packages that require them.

What alternatives have you considered?

None, as I've read somewhere than v8 dependencies are patched, which would make it impossible to use vanilla v8 alongside.

[benjamingr]

@nodejs/v8 this sounds like a good idea though probably not super practical due to the fact we float patches over v8

[joyeecheung]

If the need is to not have to rebuild V8, it seems the goal overlaps with the (very old) effort of linking Node.js with v8_monolith.a instead, but no one has been volunteering in making it work AFAIK. It just needs someone to wrestle with the gyp configs to figure out how to do it. Then it would become possible to cache the v8_monolith.a and reuse it in different Node.js builds that don't change anything in deps/v8.

[bnoordhuis]

but no one has been volunteering in making it work

/me raises hand

I plan on working on it, provided it can be done in a reasonable time frame. If anyone has concerns, now would be a good time to voice them.

[Ashvith10]

@bnoordhuis are you still interested in working on this proposal? Or perhaps, could you give a few pointers so that I can try exploring this?

[bnoordhuis]

I haven't started yet so you're welcome to it. I'd start with the monolith build. Once that works, a shared library should be relatively easy.

[alexweej]

In terms of the side quest of making a super easy way to start development without having to build everything from scratch, an approach using Docker containers seems like it would work. @billywhizz and I have been playing with this internally and it seems viable - the image we built is 2.44GB which is not that bad to pull on a fast internet connection. We found https://github.com/nodejs/devcontainer which seems to have been abandoned, but embodies the same idea?

[Ashvith10]

I think I should've phrased the issue properly, @alexweej .

In Guix/NixOS lingua, packages are dependent on other packages, called inputs. Packages are going to be built in a reproducible, isolated environment with highly-restricted network - so Docker cannot be used here. The only way to provide those packages are either through in-source dependencies or inputs.

I wish to be provided an option to remove in-source dependency contamination in NodeJS - by packing in-source dependencies as packages instead. Packages would be built only once (in both dev and build environment) and cached locally or on build farms. This would ensure that future builds would take constant time for NodeJS.

But as it turns out, NodeJS V8 is a customized fork. It is also not maintained separately, but as a in-source dependency for NodeJS, which makes it even more harder.

[alexweej]

Hey, IMO you did phrase it properly but perhaps were unclear on the "AS A __ I WANT __ SO THAT __".

AS A Node.js contributor
I WANT a ready-made working copy of Node.js to make quick edits and run the tests
SO THAT the barrier to entry is reduced for contributions

This seemed to be what @joyeecheung was referring to in #53509 (comment) above, but maybe I misunderstood.

But what you're asking is:

AS A software distributor (Nixpkgs/Debian/Red Hat)
I WANT the Node.js package build to not require an embedded vendored build of V8
SO THAT I can reduce my build compute bill and reuse the V8 build for more than just Node.js

Is that correct?

[Ashvith10]

AS A software distributor (Nixpkgs/Debian/Red Hat)
I WANT the Node.js package build to not require an embedded vendored build of V8
SO THAT I can reduce my build compute bill and reuse the V8 build for more than just Node.js

I think that this sums it perfectly.