[gentoo-dev] Upstream build uses "npm install", how to handle this in an ebuild?

[Ralph Seichter]

I am trying to add NodeJS support to www-servers/nginx-unit, but the
upstream build relies on a working network connection to download
dependencies and execute "npm install ..." during the build process.

How can this scenario be handled properly in an ebuild? I don't see
obvious existing ebuilds that I could use as a guide. Electron seems to
perform some npm wizardry, but I don't know what to make of it.

-Ralph

[Michael Orlitzky]

Post by Ralph Seichter
I am trying to add NodeJS support to www-servers/nginx-unit, but the
upstream build relies on a working network connection to download
dependencies and execute "npm install ..." during the build process.
How can this scenario be handled properly in an ebuild? I don't see
obvious existing ebuilds that I could use as a guide. Electron seems to
perform some npm wizardry, but I don't know what to make of it.

(I proposed one of those eclasses)

If you're really, really lucky you can:

* Package all of the javascript dependencies first, installing them to
/usr/lib/node_modules or wherever NodeJS is looking these days.

* Add those new packages as dependencies to your ebuild.

* Hack the build system to keep it from accessing the network during
installation.

But, you're going to have problems:

* The dependency tree for the simplest thing is hundreds of packages
long. I'm guessing you don't have time to package them all.

* In that mile-long list, there are packages that outright conflict.
So ngingx-unit might depend on dev-js/foo-1.0 which depends on
dev-js/bar-2.0 which depends on dev-js/baz-1.0 which depends on
dev-js/foo-2.0.

* There's no build system for these packages, so you can't install two
libraries simultaneously and point the program to the right version.
NodeJS upstream is actively hostile to not copy/pasting all
libraries (recursively!) into your programs.

* All of the upstream library developer are... javascript developers,
and have never used anything else and agree that this is a fine way
to do things, so they won't accept any of your PRs to make their
dependencies consistent or to use modern versions or to avoid hard-
coding the "node_modules" path everywhere or...