You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unknown env config "nodegit-binary-host-mirror". This will stop working in the next major version of npm. #3156
I'm using nodegit, which uses node-gyp to include the platform specific binaries. In my organization, I have in my .npmrc, an override for nodegit_binary_host_mirror to set the location to point to my custom repository. Using npm v11.3.0, I started getting Unknown env config "nodegit-binary-host-mirror". This will stop working in the next major version of npm. My understanding is this is a feature of node-gyp to allow for overriding the binary location. Is there an alternative being discussed?
changed the title [-]Unknown env config "nodegit-bnary-host-mirror". This will stop working in the next major version of npm.[/-][+]Unknown env config "nodegit-binary-host-mirror". This will stop working in the next major version of npm.[/+]on Apr 27, 2025
@rcolfin Yes that was my thinking as well. node-gyp would need to support that as well as the current ways of setting configs as to not be a breaking change. But at least then users can migrate to get rid of the warnings.
That won't work for nodedir which needs to be configurable globally. Package.json isn't really an acceptable place for these kinds of configs at all, which is something the npm folks didn't manage to understand.
Given that the install scripts are executed during an npm install, it looks like the fields are accessible via a convention where the particular key has the process.env.npm_package_config_ prefix.
In my case, if defined under the config in package.json then nodegit_binary_host_mirror, would be accessible via process.env.npm_package_config_nodegit_binary_host_mirror.
Would need to verify if this is the case, if so, it sounds like it should work to include this as part of the resolution for the mirror.
Which issue did you raise? If package.json is meant to be a replacement for the npm config, then it seems relevant in this case as a viable alternative.
Which issue did you raise? If package.json is meant to be a replacement for the npm config, then it seems relevant in this case as a viable alternative.
My issue was that all config for node gyp won't work in env vars and npmrc, which means that config that needs to be set globally needs a new home, for which package.json obviously makes no sense. It was closed as a dup of this issue. But if putting things into each and every package.json is the solution to this issue then mine is not a dup of it.
Yeah, I understand it makes maintaining more painful to localize it in the package.json that uses node-gyp. In my case it is isolated to one project that has this dependency. In that case, I believe the change I mentioned previously would work.
One thought though is if this is by convention using environment variables, could you set this as a bootstrap step to working in your project? Set it in the bashrc or import as a dotenv before running the install.
One thought though is if this is by convention using environment variables, could you set this as a bootstrap step to working in your project? Set it in the bashrc or import as a dotenv before running the install.
If setting in package.json is not an option for you, then I would agree with this suggestion. Setting npm_package_config_devdir (or whatever we end up reading from in node-gyp, see below) in your environment is the best option.
And I believe these are still the same issue since it will all be solved by node-gyp reading those environment variables since setting them in the package.json will propagate to the env.
Since config is still technically a global store, should we use this opporunity to prefix things with node_gyp in there as well? This means you would set env vars like npm_package_config_node_gyp_devdir and in the package.json as
Maybe, but that still doesn't address projects that have nothing to do with each other which are in completely different parts of the filesystem.
Also, I'm pretty sure my colleagues don't want my node-gyp config on their machines, I definitely don't want theirs nor that of any random project on the internet. So package.json which gets committed to the repo, seems a poor place for this.
an env var that doesn't start with npm so that npm doesn't filter it out.
npm isnt going to strip out all env vars that start with npm_. what i posted above uses the npm_package_config_ prefix for the env vars which npm will pass along to the scripts.
Here's an example to clarify what I was saying above (notice there are no npm warnings):
╰❯ npm --version
11.5.2
# If you want to set the devdir per project use `config` in package.json like this:
╰❯ cat package.json
{
"name": "npm-11-node-gyp",
"scripts": {
"env": "env | grep -i _devdir"
},
"config": {
"node_gyp_devdir": "1"
}
}
# Then scripts will have access to that value as `npm_package_config_node_gyp_devdir`
╰❯ npm run env
> env
> env | grep -i _devdir
npm_package_config_node_gyp_devdir=1
# Or without using package.json, set the same env var:
╰❯ npm pkg delete config
╰❯ npm_package_config_node_gyp_devdir=2 npm run env
> env
> env | grep -i _devdir
npm_package_config_node_gyp_devdir=2
The change required in node-gyp would be to read these additional env vars.
This doesn't make sense, it's still just one project, since package.json is in the project, right? It's not global by definition.
By "global" I meant global for the ecosystem. Any tool can prescribe using package.json#config for its config values, so I think we should prefix any that we intend to read with node_gyp_.
@rcolfin Looking at the original issue body, I don't see anywhere that node-gyp is using or setting the nodegit_binary_host_mirror value. Could that be used only in nodegit?
npm allows for the prefix npm_package_config_ for this use case. We can also make node-gyp read another env prefix but for now I think aligning with npm's preferred solution makes sense. I opened #3196 with this change.
I'm going to reopen this issue since I can't figure out what the nodegit_binary_host_mirror env var is supposed to configure, and I want to ensure there's nothing else to be done on the node-gyp side. But I can't find mention of this env var in the code.
So this might be close-able as an upstream issue in nodegit? I have not used it before and I can't yet figure out how it's reading those env vars.
I believe node-gyp by convention adds the binary_host_mirror to the package name. You wouldn't see it within node-gyp itself.
@rcolfin Looking at the original issue body, I don't see anywhere that node-gyp is using or setting the nodegit_binary_host_mirror value. Could that be used only in nodegit?
@lukekarrys are you looking for a poc where the config defined in the package.json translate successfully to the environment variables resolving to the binary mirror location?
Activity
[-]Unknown env config "nodegit-bnary-host-mirror". This will stop working in the next major version of npm.[/-][+]Unknown env config "nodegit-binary-host-mirror". This will stop working in the next major version of npm.[/+]lukekarrys commentedon Aug 11, 2025
Linking to an
npm/cliissue for reference from #3192: npm/cli#8153rcolfin commentedon Aug 13, 2025
As a follow up to @lukekarrys comment, adding the config section in package.json; ie:
Correct me if I am wrong, but I believe
node-gypwould need to be updated in order to read the config from the config section of package.json.lukekarrys commentedon Aug 13, 2025
@rcolfin Yes that was my thinking as well.
node-gypwould need to support that as well as the current ways of setting configs as to not be a breaking change. But at least then users can migrate to get rid of the warnings.CamJN commentedon Aug 13, 2025
That won't work for nodedir which needs to be configurable globally. Package.json isn't really an acceptable place for these kinds of configs at all, which is something the npm folks didn't manage to understand.
rcolfin commentedon Aug 14, 2025
Given that the install scripts are executed during an npm install, it looks like the fields are accessible via a convention where the particular key has the process.env.npm_package_config_ prefix.
In my case, if defined under the config in package.json then nodegit_binary_host_mirror, would be accessible via process.env.npm_package_config_nodegit_binary_host_mirror.
Would need to verify if this is the case, if so, it sounds like it should work to include this as part of the resolution for the mirror.
CamJN commentedon Aug 14, 2025
package.json isn't relevant here, or if it is then my issue should be reopened.
rcolfin commentedon Aug 14, 2025
Which issue did you raise? If package.json is meant to be a replacement for the npm config, then it seems relevant in this case as a viable alternative.
rcolfin commentedon Aug 14, 2025
Potential fix could be if npm_package_config_ prefix is added to node-pre-gyp.js#L172.
CamJN commentedon Aug 14, 2025
My issue was that all config for node gyp won't work in env vars and npmrc, which means that config that needs to be set globally needs a new home, for which package.json obviously makes no sense. It was closed as a dup of this issue. But if putting things into each and every package.json is the solution to this issue then mine is not a dup of it.
rcolfin commentedon Aug 14, 2025
Yeah, I understand it makes maintaining more painful to localize it in the package.json that uses node-gyp. In my case it is isolated to one project that has this dependency. In that case, I believe the change I mentioned previously would work.
One thought though is if this is by convention using environment variables, could you set this as a bootstrap step to working in your project? Set it in the bashrc or import as a dotenv before running the install.
lukekarrys commentedon Aug 14, 2025
If setting in package.json is not an option for you, then I would agree with this suggestion. Setting
npm_package_config_devdir(or whatever we end up reading from in node-gyp, see below) in your environment is the best option.And I believe these are still the same issue since it will all be solved by
node-gypreading those environment variables since setting them in the package.json will propagate to the env.Since
configis still technically a global store, should we use this opporunity to prefix things withnode_gypin there as well? This means you would set env vars likenpm_package_config_node_gyp_devdirand in the package.json asCamJN commentedon Aug 14, 2025
The npm prefixed env var won't work but a node gyp prefixed env var should.
This doesn't make sense, it's still just one project, since package.json is in the project, right? It's not global by definition.
rcolfin commentedon Aug 14, 2025
I wondered in the case of an npm workspace, would setting it in the root package.json suffice for all the projects underneath.
CamJN commentedon Aug 14, 2025
Maybe, but that still doesn't address projects that have nothing to do with each other which are in completely different parts of the filesystem.
Also, I'm pretty sure my colleagues don't want my node-gyp config on their machines, I definitely don't want theirs nor that of any random project on the internet. So package.json which gets committed to the repo, seems a poor place for this.
3 remaining items
lukekarrys commentedon Aug 14, 2025
npm isnt going to strip out all env vars that start with
npm_. what i posted above uses thenpm_package_config_prefix for the env vars which npm will pass along to the scripts.Here's an example to clarify what I was saying above (notice there are no npm warnings):
The change required in
node-gypwould be to read these additional env vars.lukekarrys commentedon Aug 14, 2025
By "global" I meant global for the ecosystem. Any tool can prescribe using
package.json#configfor its config values, so I think we should prefix any that we intend to read withnode_gyp_.feat: read package.json config values
lukekarrys commentedon Aug 14, 2025
@rcolfin Looking at the original issue body, I don't see anywhere that node-gyp is using or setting the
nodegit_binary_host_mirrorvalue. Could that be used only innodegit?CamJN commentedon Aug 14, 2025
I mean, the ones that start with
npm_config_for sure, per their warning. But why would they allownpm_but notnpm_config_?lukekarrys commentedon Aug 15, 2025
npm allows for the prefix
npm_package_config_for this use case. We can also makenode-gypread another env prefix but for now I think aligning with npm's preferred solution makes sense. I opened #3196 with this change.lukekarrys commentedon Aug 19, 2025
I'm going to reopen this issue since I can't figure out what the
nodegit_binary_host_mirrorenv var is supposed to configure, and I want to ensure there's nothing else to be done on thenode-gypside. But I can't find mention of this env var in the code.So this might be close-able as an upstream issue in
nodegit? I have not used it before and I can't yet figure out how it's reading those env vars.feat: support reading config from package.json (nodejs#3196)
rcolfin commentedon Aug 21, 2025
I believe node-gyp by convention adds the binary_host_mirror to the package name. You wouldn't see it within node-gyp itself.
rcolfin commentedon Aug 25, 2025
@lukekarrys are you looking for a poc where the config defined in the package.json translate successfully to the environment variables resolving to the binary mirror location?
chore: pass nodedir to node-gyp via npm_package_config env in node in…