Unknown env config "nodegit-binary-host-mirror". This will stop working in the next major version of npm.

[rcolfin]

Hi,

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?

Thanks,
Rob

[lukekarrys]

Linking to an npm/cli issue for reference from #3192: npm/cli#8153

• Node-gyp config instructions are going to stop working soon #3192
  • "Unknown user/project config" warnings starting in npm 11.2.0 npm/cli#8153

[rcolfin]

As a follow up to @lukekarrys comment, adding the config section in package.json; ie:

"config": {
    "nodegit_binary_host_mirror": "http://other-domain/nodegit"
}

Correct me if I am wrong, but I believe node-gyp would need to be updated in order to read the config from the config section of package.json.

[lukekarrys]

@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.

[CamJN]

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]

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]

package.json isn't relevant here, or if it is then my issue should be reopened.

[rcolfin]

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]

Potential fix could be if npm_package_config_ prefix is added to node-pre-gyp.js#L172.

[CamJN]

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.

[rcolfin]

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]

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

"config": {
    "node_gyp_devdir": "/some/other/dir/just-for-this-project"
}

[CamJN]

The npm prefixed env var won't work but a node gyp prefixed env var should.

Since config is still technically a global store, should we use this opporunity to prefix things with node_gyp in there as well?

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]

The npm prefixed env var won't work but a node gyp prefixed env var should.

Since config is still technically a global store, should we use this opporunity to prefix things with node_gyp in there as well?

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.

I wondered in the case of an npm workspace, would setting it in the root package.json suffice for all the projects underneath.

[CamJN]

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.