Observed in node-gyp@12.4.0
node-gyp supports custom Node.js distribution mirrors via --dist-url / node_gyp_dist_url, but there does not appear to be a documented way to authenticate requests made to that mirror.
This is a problem in corporate environments where Node.js distributions and headers are served through an authenticated Artifactory mirror.
Example failure
gyp http GET https://artifactory.example.com/artifactory/nodejs-dist/v24.19.0/node-v24.19.0-headers.tar.gz
gyp http 401 https://artifactory.example.com/artifactory/nodejs-dist/v24.19.0/node-v24.19.0-headers.tar.gz
Package installation itself works because npm, pnpm, or Yarn can authenticate against the package registry. The failure happens later, when node-gyp downloads Node.js headers from the configured distribution URL.
Example package registry authentication:
registry=https://artifactory.example.com/artifactory/api/npm/npm-virtual/
//artifactory.example.com/artifactory/api/npm/npm-virtual/:_authToken=${NPM_TOKEN}
Example Node.js distribution mirror:
https://artifactory.example.com/artifactory/nodejs-dist/
Example node-gyp configuration:
npm_package_config_node_gyp_dist_url=https://artifactory.example.com/artifactory/nodejs-dist
Expected behavior
When --dist-url / node_gyp_dist_url points to an authenticated mirror, node-gyp should provide a supported way to authenticate downloads from that mirror.
Authentication would need to apply consistently to:
- the Node.js headers tarball;
SHASUMS256.txt;
- Windows
node.lib files;
- any other files downloaded from the configured distribution URL.
Possible solutions
Any of the following would solve the issue. Explicit node-gyp configuration may be preferable given npm's move away from unsupported custom .npmrc keys.
1. Add explicit node-gyp authentication configuration
For example:
node-gyp rebuild \
--dist-url=https://artifactory.example.com/artifactory/nodejs-dist \
--dist-url-auth-token="$NODE_GYP_DIST_TOKEN"
Or through lifecycle-safe configuration:
npm_package_config_node_gyp_dist_url_auth_token=$NODE_GYP_DIST_TOKEN
The option name could be adjusted to match the project's preferred naming and credential model.
2. Support an explicit authentication-header option
For example:
node-gyp rebuild \
--dist-url=https://artifactory.example.com/artifactory/nodejs-dist \
--dist-url-auth-header="Authorization: Bearer $NODE_GYP_DIST_TOKEN"
A credential-specific option may be safer than accepting arbitrary headers, but some environments require non-standard authentication headers.
3. Optionally support npm-compatible URL-scoped authentication
For example:
//artifactory.example.com/artifactory/nodejs-dist/:_authToken=${NODE_GYP_DIST_TOKEN}
This should only be considered if it can be implemented as documented, supported node-gyp behavior rather than relying on arbitrary unsupported .npmrc keys.
Implementation context
The downloads appear to be centralized through node-gyp's download helper. The headers tarball, checksum file, and Windows node.lib requests all use the same download path, where request headers are currently constructed.
This seems like a relatively contained integration point: authentication could be resolved once for the configured dist-url and applied to all requests made within that distribution scope.
Security considerations
- Credentials should only be sent to URLs under the configured
dist-url.
- Credentials must not be logged, including with verbose or silly logging.
- Credentials should not be forwarded across redirects to a different host.
- Environment-variable-based configuration should be supported so secrets do not need to be committed.
- Authentication should be applied consistently to the tarball, checksum, and
node.lib requests.
- If npm-compatible credentials are supported, matching should respect the configured URL scope rather than sending credentials to every URL on the same host.
- Credentials should not appear in error messages, generated files, or process arguments where avoidable.
Current workarounds
There are partial workarounds, but they are difficult to apply reliably in package-manager-driven installs:
--nodedir requires a compatible local Node.js headers/source tree and a way to pass the option to the actual transitive node-gyp invocation.
--tarball can avoid network access, but it requires invoking node-gyp install explicitly before the dependency rebuild.
- Manually pre-populating node-gyp's cache is brittle because the cache must match node-gyp's expected layout and metadata, including
installVersion.
- Embedding credentials in
--dist-url only works when the mirror accepts Basic Auth and may expose credentials in logs or process arguments.
In practice, these workarounds are difficult to standardize across developer machines and CI systems when native modules invoke node-gyp indirectly during installation or bootstrapping.
Related issues
This appears related to:
Question
Would maintainers be open to supporting authentication for private --dist-url mirrors?
If so, would URL-scoped npm-compatible authentication or explicit node-gyp-specific authentication options be preferred?
Observed in
node-gyp@12.4.0node-gypsupports custom Node.js distribution mirrors via--dist-url/node_gyp_dist_url, but there does not appear to be a documented way to authenticate requests made to that mirror.This is a problem in corporate environments where Node.js distributions and headers are served through an authenticated Artifactory mirror.
Example failure
Package installation itself works because npm, pnpm, or Yarn can authenticate against the package registry. The failure happens later, when
node-gypdownloads Node.js headers from the configured distribution URL.Example package registry authentication:
Example Node.js distribution mirror:
Example node-gyp configuration:
Expected behavior
When
--dist-url/node_gyp_dist_urlpoints to an authenticated mirror,node-gypshould provide a supported way to authenticate downloads from that mirror.Authentication would need to apply consistently to:
SHASUMS256.txt;node.libfiles;Possible solutions
Any of the following would solve the issue. Explicit node-gyp configuration may be preferable given npm's move away from unsupported custom
.npmrckeys.1. Add explicit node-gyp authentication configuration
For example:
node-gyp rebuild \ --dist-url=https://artifactory.example.com/artifactory/nodejs-dist \ --dist-url-auth-token="$NODE_GYP_DIST_TOKEN"Or through lifecycle-safe configuration:
npm_package_config_node_gyp_dist_url_auth_token=$NODE_GYP_DIST_TOKENThe option name could be adjusted to match the project's preferred naming and credential model.
2. Support an explicit authentication-header option
For example:
node-gyp rebuild \ --dist-url=https://artifactory.example.com/artifactory/nodejs-dist \ --dist-url-auth-header="Authorization: Bearer $NODE_GYP_DIST_TOKEN"A credential-specific option may be safer than accepting arbitrary headers, but some environments require non-standard authentication headers.
3. Optionally support npm-compatible URL-scoped authentication
For example:
//artifactory.example.com/artifactory/nodejs-dist/:_authToken=${NODE_GYP_DIST_TOKEN}This should only be considered if it can be implemented as documented, supported node-gyp behavior rather than relying on arbitrary unsupported
.npmrckeys.Implementation context
The downloads appear to be centralized through node-gyp's download helper. The headers tarball, checksum file, and Windows
node.librequests all use the same download path, where request headers are currently constructed.This seems like a relatively contained integration point: authentication could be resolved once for the configured
dist-urland applied to all requests made within that distribution scope.Security considerations
dist-url.node.librequests.Current workarounds
There are partial workarounds, but they are difficult to apply reliably in package-manager-driven installs:
--nodedirrequires a compatible local Node.js headers/source tree and a way to pass the option to the actual transitivenode-gypinvocation.--tarballcan avoid network access, but it requires invokingnode-gyp installexplicitly before the dependency rebuild.installVersion.--dist-urlonly works when the mirror accepts Basic Auth and may expose credentials in logs or process arguments.In practice, these workarounds are difficult to standardize across developer machines and CI systems when native modules invoke
node-gypindirectly during installation or bootstrapping.Related issues
This appears related to:
Question
Would maintainers be open to supporting authentication for private
--dist-urlmirrors?If so, would URL-scoped npm-compatible authentication or explicit node-gyp-specific authentication options be preferred?