Node-gyp: Should be a flag to prevent node-gyp from checking for the updated Node.js headers during 'npm build'

[yurivict]

Please see the original issue description here: https://github.com/npm/npm/issues/10402

[bnoordhuis]

It exists. Pass --nodedir /path/to/files on the command line or set npm_config_nodedir=/path/to/files in the environment.

[yurivict]

Adding --nodedir /path/to/files seems to stop build altogether.
I tried all these directories - the whole build doesn't happen when --nodedir is set:

--nodedir /usr/local/lib/node_modules/npm/node_modules
--nodedir /usr/local/lib/node_modules/npm
--nodedir /usr/local/lib/node_modules
--nodedir /usr/local/lib
--nodedir /usr/local
--nodedir /usr/ports/www/etherpad-lite/work/etherpad-lite-1.5.7/node_modules/ep_etherpad-lite/node_modules
--nodedir /usr/ports/www/etherpad-lite/work/etherpad-lite-1.5.7/node_modules/ep_etherpad-lite
--nodedir /usr/ports/www/etherpad-lite/work/etherpad-lite-1.5.7/node_modules
--nodedir /usr/ports/www/etherpad-lite/work/etherpad-lite-1.5.7

[bnoordhuis]

You need to point it to a directory containing the source tree. If you extracted the tarball to (or checked out https://github.com/nodejs/node in) /opt/src/node, then pass --nodedir /opt/src/node.

[yurivict]

My node is installed by npm and node packages.
For example, the node file deps/npm/lib/cache/add-named.js is installed as /usr/local/lib/node_modules/npm/lib/cache/add-named.js.

When I try to pass some non-existent directory --nodedir /weird, build doesn't happen, but system call trace doesn't show any system call with the word 'weird' in it. So it looks like 'npm rebuild' doesn't use the supplied directory at all.

[bnoordhuis]

npm rebuild itself won't, it's only node-gyp that acts on it and that's only executed when a module has native components, i.e., when there is a binding.gyp in its top-level directory.

[yurivict]

Some modules do have native code that needs to be rebuilt (binding.gyp files exist), so node-gyp is invoked.

I checked out the fresh copy of node into /home/yuri/github/node, and run this command:

CC=cc CXX=c++ npm rebuild --nodedir /home/yuri/github/node

It doesn't build anything, even though there is ./node_modules/ep_etherpad-lite/node_modules/sqlite3/binding.gyp that needs to build.

Without --nodedir it does build. I only expected --nodedir to stop connecting to nodejs.org during rebuild, and it stops the build altogether

What am I doing wrong?

[yurivict]

I run NodeJS from the installation (node+npm ports). There should be no need to pass --nodedir because it is known (installed files).

What I really need is --no-downloads flag, telling node-gyp to not connect anywhere, and only use what it has.

[bnoordhuis]

If you have trouble with npm rebuild, I suggest you file an issue here. node-gyp rebuild --nodedir <path> should still work.

Caveat emptor, I believe node-sqlite3 uses node-pre-gyp (different project) that downloads a pre-compiled add-on and only builds locally as a fallback. You'll want to check that first because looking at the npm issue you linked to, that's what is actually being downloaded.

[jsumners]

The problem is that his system doesn't have a direct, or proxied, connection to the Internet. Therefore, _any_ "gyp" module that tries to download _anything_ is going to fail. I'm here with the same problem trying to figure out a way to make the stupid oracledb module compile. My situation is compounded by the fact that I'm using Ansible's npm module to run the install, and it doesn't support adding in extra switches (I'm probably going to submit a bug report on that).

In my opinion, at the very least node-gyp should try to establish the connection, preferably in a fail fast manner, and then go with the configured node environment on failure. But I'd rather it go with the configured node environment by default and only try to download updated stuff _if_ I tell it to.

[bnoordhuis]

go with the configured node environment on failure

What do you mean, 'configured node environment'?

[jsumners]

I suppose it would require a quick check. Let's say the node binary is at /usr/local/bin/node. Then one could reasonably assume, and test it to be true, that /usr/local/include/node/ contains the headers shipped with the tarball. Thus, the "node environment" is based upon the path to the node binary.

FWIW, specifying --nodedir=/usr/local solves the issue for me. But it took a fair amount of searching to discover that's what I needed to do. The node-gyp readme doesn't mention it at all, and neither does the error message when the build fails. Without finding this issue, I wouldn't have known what to do. Because reading the addons docs for a single bullet point that is more targeted toward native module developers, is not something I would have thought to do -- https://nodejs.org/dist/latest-v4.x/docs/api/addons.html#addons_linking_to_node_js_own_dependencies (I only stumbled upon it while researching this reply).

[bnoordhuis]

I'd be really loath to adopt such behavior because of the very obscure failure modes it can introduce; think mismatched headers and such. At least with a network error you know where you stand.

An acceptable middle ground is perhaps having node-gyp print a message suggesting you retry with --nodedir=/usr/local (actual path derived from process.execPath.)

[jsumners]

Sounds fair to me. It at least gives you a place to start.

[bnoordhuis]

I'm putting this on my TODO list but if anyone else wants to work on it, I'll be happy to review pull requests.

[jonathanwcrane]

+1 for this problem. Still solving it but this issue gave me an avenue to look down.

[rvagg]

closing due to staleness but a PR would be great to get it moving again if someone feels strongly enough