`npm warn Unknown env config` with npm 11.2.0 create friction.

[garronej]

Hello NPM team,

Since NPM CLI version 11.2, I'm experiencing notable friction as a devtool and CLI maintainer caused by new warnings related to unrecognized environment configs set by other package managers (e.g., pnpm, Yarn).

Specifically, I'm referring to warnings such as:

npm warn Unknown env config "version-git-tag". This will stop working in the next major version of npm.
npm warn Unknown env config "argv". This will stop working in the next major version of npm.
npm warn Unknown env config "version-commit-hooks". This will stop working in the next major version of npm.
npm warn Unknown env config "version-git-message". This will stop working in the next major version of npm.
npm warn Unknown env config "version-tag-prefix". This will stop working in the next major version of npm.

Why this matters:

Previously, I could confidently write my CLI tools and technical documentation assuming that, regardless of the package manager that my user are using to initiate the execution of the script (example pnpm run <srcipt> or pnpm exec <bin name>):

npx <bin name>
npm run <script>
npm config get

This always provided consistent, reliable results independent of how users actually initiated the execution of my CLI.

Concrete example:

Consider this starter repo where the package.json defines:

"scripts": {
  "build": "tsc -b && vite build",
  "build-keycloak-theme": "npm run build && keycloakify build"
}

When users follow these straightforward instructions:

git clone https://github.com/keycloakify/keycloakify-starter
cd keycloakify-starter
npm install
npm run build-keycloak-theme

Everything works flawlessly, no warnings.

However, if users choose a different package manager like pnpm, executing:

pnpm run build-keycloak-theme

now triggers multiple warnings due to environment variables that pnpm sets internally.

Impact on maintainers and users:

As a maintainer, I face substantial friction. To avoid confusing warnings for users, I must either instruct them explicitly to modify scripts per package manager (e.g., replacing npm run with pnpm run).

Additionally for the NPM command that I ran in my CLIs I must now make sure to swallow all thoses warnings so that they are not surfaced to the user.

Currently, every command invocation floods terminals with irrelevant warnings like this:

Suggested approach:

I fully understand these warnings are not strictly bugs; however, given NPM's unique position as the default package manager present in nearly every Node.js setup, it's incredibly beneficial to rely on NPM commands consistently across user environments, even those that manage dependencies with other package managers.

Could these warnings perhaps be reconsidered?

Thank you sincerely for considering this feedback, and thanks as always for your work maintaining NPM!

Best regards,

[wraithgar]

Could these warnings perhaps be reconsidered?

This is not likely to be reconsidered.

These warnings are in preparation for this config to stop working in the future. It is a very dangerous thing to allow unconfigured entries in npm's own config files. There are other ways to configure things for scripts themselves, including the config object in the package.json itself.

If npm were to add its own version-git-tag config in the future, it would collide with yours. This is the reason for the warnings and eventual removal. It's unfortunate that there were never warnings before, and that folks were able to use this shortcut instead of using a valid external config setup. This is a necessary pain point in order to clean things up and prevent even worse problems in the future. npm needs to be able to add config in the future without breaking users.

now triggers multiple warnings due to environment variables that pnpm sets internally.

This seems like a different problem outside the scope of npm itself.

[darksabrefr]

@wraithgar Please don't close this issue too early. The problem is not that npm produces warnings but that it will crash in a near future in such situations.
There's many cases where interactions exist between npm and other package managers. It will cause real world problems in many and unexpected places.
You may argue that's not your fault/your war and that others folks have hijacked this npm feature, and you will probably be right. But the fact is that this issue is not an isolated thing caused by a bad conf. It always exists when another package manager interacts with npm, and those are widely used tools.
I really think this issue has to be carefully handled because it has a very high risk level of creating many problems in the future.
So, please reconsider, not the warnings, but the related future big breaking change.

[garronej]

Thank you @darksabrefr for making your point!

And yes, again @wraithgar, while I fully understand where you're coming from and agree that your reasoning makes sense from your perspective, I don't think the full extent of the additional burden this change places on CLI maintainers and technical documentation authors is being acknowledged.

The fact that I can no longer write a package.json that is agnostic to the package manager (i.e., can't rely on npm run <script> ins the scripts section) is an immense pain point.

Sure, I can fix all my CLIs. It’ll take time, but it’s doable. I'll have to test what package manager is in use in the repo and use the equivalent commands (e.g. npm run <script> -> yarn <script>). What I can’t solve, and what’s genuinely stressing me out, is the use of npm run <script> in package.json.

[darksabrefr]

Sure, I can fix all my CLIs. It’ll take time, but it’s doable. I'll have to test what package manager is in use in the repo and use the equivalent commands (e.g. npm run <script> -> yarn <script>). What I can’t solve, and what’s genuinely stressing me out, is the use of npm run <script> in package.json.

There's a very simple case that is not trivially fixable :

• add a prepare script in your package.json, with npm run or npx inside
• yarn install
• once the dependencies are installed, the prepare script is executed with the hijacked env variables set by yarn

A more problematic case : you can encounter an equivalent situation, but with no way to address it this time, if a dependency register an install script with a call to npm/npx in its package.json. Here, you can't change/fix the script and you can't unset the "bad" env variables.

[garronej]

There's a very simple case that is not trivially fixable...

Yes 100%. Yes exactly.
I expect the answer from @wraithgar to be "just replace npm run by yarn run if you are using yarn" but that's a problem for project starters and documentation.

A more problematic case : you can encounter an equivalent situation, but with no way to address it this time, if a dependency register an install script with a call to npm/npx in its package.json. Here, you can't change/fix the script and you can't unset the "bad" env variables.

Exactly, the only way to fix is for the maintainer of the script to carefully cherrypick the env passed to child_process.exec() and not everyone is going to do that.

[ch3ll0v3k]

in my case it was bcs of npx cross-env if using without npx, cross-env all warning are gone.
maybe will help some one