| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Linking to an npm/cli issue for reference from #3192: npm/cli#8153
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.
@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.
package.json isn't relevant here, or if it is then my issue should be reopened.
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.
Potential fix could be if npm_package_config_ prefix is added to node-pre-gyp.js#L172.
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
"config": {
"node_gyp_devdir": "/some/other/dir/just-for-this-project"
}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.
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.
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=2The 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 isnt going to strip out all env vars that start with npm_
I mean, the ones that start with npm_config_ for sure, per their warning. But why would they allow npm_ but not npm_config_?
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?
| Back | FazBrowse Home | New Git URL |
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