[BUG] config var "`node-gyp`" not respected in npm 7

[DeeDeeG]

Current Behavior:

Unlike in npm v6, the node-gyp config var is not respected.

(This config option sets a custom path to a working node-gyp install's bin/node-gyp.js file. When set, npm will attempt to use this copy of node-gyp if executing node-gyp to build native C++ code.)

Expected Behavior:

node-gyp at the custom path is used. (At the path set in the node-gyp config var.)

Steps To Reproduce:

0. If you don't have one already, obtain a copy of node-gyp (an extra copy not bundled with npm) and install its dependencies:
   i. git clone https://github.com/nodejs/node-gyp
   ii. cd node-gyp && npm install
1. Specify a node-gyp config var somehow. See the following options to do so:
   a) Do npm config set node-gyp=/path/to/node-gyp/bin/node-gyp.js
   b1) Do export npm_config_node_gyp=/path/to/node-gyp/bin/node-gyp.js (Linux/macOS)
   b2) Do Set npm_config_node_gyp=C:/path/to/node-gyp/bin/node-gyp.js (Windows)
   c) Use this flag with npm commands: --node-gyp=/path/to/node-gyp/bin/node-gyp.js
2. In any project that depends on a module with native code... run npm rebuild --verbose --foreground-scripts

Note that the path of node-gyp is printed next to a cli label in the verbose output.

For example (cli output, click to expand):

gyp verb cli [
gyp verb cli   '/Users/[user]/n-prefix/bin/node',
gyp verb cli   '/Users/[user]/n-prefix/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js',
gyp verb cli   'rebuild'
gyp verb cli ]

• With npm 6, the node-gyp config var is respected, and the node-gyp at the custom path is used.
• With npm 7, the node-gyp config var is not respected. Regardless of the config var, node-gyp bundled with the running npm is used, OR if there is a copy of node-gyp as a top-level dependency in the project's node_modules folder, that copy from the local node_modules/node-gyp is used.

Environment:

• OS: macOS 10.15.7
• Node: 12.4.0
• npm: 7.6.1

Related issue?

I think I tracked down the problem to the @npmcli/run-script module. See this issue I created at that repository for my best guess as to why this is happening: npm/run-script#23

[DeeDeeG]

I tested this by "poisoning" a copy of node-gyp so I'd be sure if it was used or not.

Simply put this at the beginning of the node-gyp/bin/node-gyp.js file:

throw new Error('hello from poisoned node-gyp')

I used to be able to specify what copy of node-gyp npm used with the node-gyp config var, but this stopped working in npm 7.

---

I didn't see any RFCs about this, so it's either an undocumented behavior change, or it's an oversight/bug.

I'd appreciate some clarity on whether it's meant to be deprecated or dropped functionality, in which case documenting that somewhere would be great, or if it's considered a bug, some pointers on how to get the bug fixed.

[tavrez]

I also find this issue, but I think it's node_gyp not node-gyp, am I right?

[DeeDeeG]

@tavrez thanks for another person confirming this issue.

Both variable names (with underscore or dash) can be used interchangeably, at least in npm 6.

• Env var npm_config_node_gyp or npm_config_node-gyp (this var name works in a case-insensitive way)
• npm config var set in a .npmrc file, as npm config set node_gyp or npm config set node-gyp (also case-insensitive)
• Command-line flag for npm:
  • npm rebuild --verbose --node_gyp=[path/to/node-gyp/bin/node-gyp.js] (flag --node-gyp must be all lowercase), or
  • npm rebuild --verbose --node-gyp=[path/to/node-gyp/bin/node-gyp.js] (flag --node_gyp also must be all lowercase)

[DeeDeeG]

I have a CI test that uses this npm config var to test whether spaces in paths can cause an issue.

I would have to disable or re-write the test if we upgrade our infrastructure to use npm 7 instead of npm 6. Any thoughts on whether this might be fixed, or labelled "won'tfix", would be appreciated so I can know whether to re-write/delete the test, or just wait for the fix.

Thanks.

[darcyclarke]

This is a known issue; We'll try to resolve this when we upgrade to node-gyp@8.x in the very near future.

[DeeDeeG]

I think this is an unintended consequence of npm/run-script@e4c7cb3 ?

Might be the same underlying cause as what causes #3058.