[discussion] How to handle devEngines.packageManager when one package manager calls another one for some commands

[zkochan]

Currently the only way to ignore the devEngines check is to use the --force flag: https://github.com/npm/cli/blob/d006583e20731e8ae55cee94c3b7bd23cbd6f2d0/lib/base-cmd.js#L174

But that flag makes npm print a warning and also changes other things.

pnpm is passing through some commands to npm CLI (like dist-tag, publish, view, etc). So, we want to be able to run npm from pnpm, even if devEngines is set to pnpm only. Alternatively, we could recommend users to put both npm and pnpm to devEngines but then they might accidentally run "npm install" instead of "pnpm install".

Maybe you could add support for an environment variable that pnpm could set, when running npm CLI.

[wraithgar]

So this is a case where npm is being ran from pnpm for one of the various subtasks that it delegates to npm? Very interesting. Is there some sort of well-defined environment variable that pnpm sets so that npm can reliably know that we are actually "being ran from pnpm"?

[lishaduck]

Is there some sort of well-defined environment variable that pnpm sets so that npm can reliably know that we are actually "being ran from pnpm"?

Sort of? https://github.com/pnpm/pnpm/blob/0748be2424b83cd988e5414883437c10ba657ec1/exec/run-npm/src/index.ts#L17
Overloading a COREPACK_ variable probably wouldn’t be wise though…

[wraithgar]

It looks like pnpm sets npm_config_user_agent in the environment, which npm will pick up and set as its own user-agent config

~ $ set -x npm_config_user_agent 'gar/test 1.0.0 neat'
~ $ npm config get user-agent
gar/test 1.0.0 neat

[lishaduck]

It looks like pnpm sets npm_config_user_agent in the environment, which npm will pick up and set as its own user-agent config

Do you really want to hardcode in pnpm support? What if, for example, Vlt decided to shell out? Or pnpm updated their UA?
IDK, maybe it’s a stable enough list it’s fine, but it feels fragile.

[wraithgar]

I don't think it's outside the realm of practicality to parse the user-agent in a way that informs the packageManager portion of the engines check. Your points are valid though, in that this is being coupled to something without any really well defined spec, but more of a history of pretty stable patterns. It would be much more robust to have this be well defined.

This currently seems like an intractable problem due to the following unanswered questions (and there may be more.

• What is a reproducible canonical way to know what package manager name and version is being used?
• What does it actually mean to limit packageManager in devEngines?
• If package manager A shells out to package manager B for operations, does the version of package manager B matter?

Ignoring these warnings is dangerous, but without any kind of roadmap to have a better way to know if they need to be displayed, my fear is that this is the direction folks will go. I am going to close this issue not because it is not real, but because this is a much larger question than we can track in this context. I am going to move this issue to our rfc repo, which is where larger discussions like this take place.

[wraithgar]

One solution could be that we update the devEngines spec to isolate for certain commands. Unfortunately npm will currently exit with an error if it encounters invalid properties in the devEngines field.

  "devEngines": {
    "os": {
      "other": "thing",
      "name": "windows",
      "onFail": "error"
    }
  }

~/D/s/devEngines $ npm ls
npm error Invalid property "other" for "os"
npm error A complete log of this run can be found in: /Users/wraithgar/.npm/_logs/2025-08-21T20_37_08_222Z-debug-0.log
~/D/s/devEngines $ npm pkg get devEngines
npm error Invalid property "other" for "os"
npm error A complete log of this run can be found in: /Users/wraithgar/.npm/_logs/2025-08-21T20_37_16_915Z-debug-0.log

It also seems like a huge burden to require package maintainers to know or care about this very edge case part of the ecosystem. A difficult problem to solve, for sure.

[ljharb]

Maybe instead of shelling out to npm at all, pnpm could use the same packages npm uses internally? npm might not even exist on the system.

[lishaduck]

Maybe instead of shelling out to npm at all, pnpm could use the same packages npm uses internally? npm might not even exist on the system.

I suggested that here, but it was quickly rejected because a bunch of npm only exists in the CLI, for example, OIDC is only implemented in the client.
It’s too significant of a maintenance burden for pnpm (+ others) to fork npm to get at shared code, when there’s a canonical implementation sitting on every Node.js user’s computer.