npm Scripts that call other npm scripts use the wrong npm version

[TheJaredWilcurt]

package.json

{
  "name": "my-project",
  "script": {
    "start": "npm run version",
    "version": "npm -v"
  },
  "volta": {
    "node": "24.0.0",
    "npm": "11.8.0"
  }
}

Command	Result	Location
proto -V	proto 0.55.2	~/.proto/bin/proto
node -v	v24.0.0	~/.proto/tools/node/24.0.0/bin/node
npm -v	v11.8.0	~/.proto/tools/npm/11.8.0/bin/npm
npm start	v11.3.0	~/.proto/tools/node/24.0.0/node_modules/npm/bin/npm
npm run version	v11.3.0	~/.proto/tools/node/24.0.0/node_modules/npm/bin/npm

Operating system?

Any

Architecture?

Any

Relates to

• devEngines bug detecting correct npm version #921
• Proto shims seem to prevent npm OIDC environment variables from reaching npm publish #930

[milesj]

Put PROTO_LOG=trace in each script and see what it's doing.

If npm itself is hijacking PATH, there's not much we can do here.

[TheJaredWilcurt]

Updated the post with where the commands are executing from.

[TheJaredWilcurt]

Would it be possible to just replace the ~/.proto/tools/node/24.0.0/node_modules/npm (the built-in npm) folder with a symlink to ~/.proto/tools/npm/11.8.0 (the current version controlled by Proto)? Or maybe symlink it to ~/.proto/shims?

Since you'd be removing the npm version that ships with Node, you'd have to replace it with a copy in the ~/.proto/tools/npm folder, and you'd have to resolve which version to use based on the Node version, but that can be found here:

• https://nodejs.org/download/release/index.json

[milesj]

This probably won't happen for a few reasons.

• Tools are design to e isolated from each other and should only access their own directories.
• The symlink approach is problematic because we would constantly by deleting, unlinking, and linking directories during every invocation.
• If a user is using proto activate, they expect the node node_modules to exist because it then provides the built-in npm/npx/etc out of the box (like how nvm works).

[TheJaredWilcurt]

Well do you have any other ideas to correct this? You've gotten everything else to work so far, and this was the bug I was waiting on before pushing out Proto at work for teams to adopt.

Why this matters:

1. It should be impossible to be on the wrong Node/npm version. This was the case with Volta, which we are looking to replace with Proto.
   • Maybe something could be learned from their implementation?
2. When the versions are stored in devEngines and the wrong npm is invoked, it checks the devEngines and refuses to run the command.
3. Aliasing npm scripts like this is extremely common. Those using devEngines will be blocked from using this common workflow, or worse, those not using devEngines would be silently unaware that they are using the wrong version.

[milesj]

I don't have an answer here at the moment.

What is PATH inside the script?

[TheJaredWilcurt]

{
  "scripts": {
    "a": "npm run b",
    "b": "echo $PATH"
  },
  "volta": {
    "node": "24.0.0",
    "npm": "11.8.0"
  }
}

npm run b

/home/owner/GitHub/vue-doxen/node_modules/.bin
/home/owner/GitHub/node_modules/.bin
/home/owner/node_modules/.bin
/home/node_modules/.bin
/node_modules/.bin
/home/owner/.proto/tools/npm/11.8.0/node_modules/@npmcli/run-script/lib/node-gyp-bin
/home/owner/.proto/tools/node/24.0.0/bin
/home/owner/.proto/tools/node/globals/bin
/home/owner/.proto/tools/npm/11.8.0/shims
/home/owner/.proto/shims
/home/owner/.proto/bin
/home/owner/GitHub/aliases
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin
/usr/games
/usr/local/games
/snap/bin

npm run a

/home/owner/GitHub/vue-doxen/node_modules/.bin
/home/owner/GitHub/node_modules/.bin
/home/owner/node_modules/.bin
/home/node_modules/.bin
/node_modules/.bin
/home/owner/.proto/tools/node/24.0.0/lib/node_modules/npm/node_modules/@npmcli/run-script/lib/node-gyp-bin
/home/owner/GitHub/vue-doxen/node_modules/.bin
/home/owner/GitHub/node_modules/.bin
/home/owner/node_modules/.bin
/home/node_modules/.bin
/node_modules/.bin
/home/owner/.proto/tools/npm/11.8.0/node_modules/@npmcli/run-script/lib/node-gyp-bin
/home/owner/.proto/tools/node/24.0.0/bin
/home/owner/.proto/tools/node/globals/bin
/home/owner/.proto/tools/npm/11.8.0/shims
/home/owner/.proto/shims
/home/owner/.proto/bin
/home/owner/GitHub/aliases
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin
/usr/games
/usr/local/games
/snap/bin

The difference is npm run a adds the first 6 lines, after that the rest are the same

/home/owner/GitHub/vue-doxen/node_modules/.bin
/home/owner/GitHub/node_modules/.bin
/home/owner/node_modules/.bin
/home/node_modules/.bin
/node_modules/.bin
/home/owner/.proto/tools/node/24.0.0/lib/node_modules/npm/node_modules/@npmcli/run-script/lib/node-gyp-bin

But none of these locations contain npm.

---

If I do whereis npm it gives

/home/owner/.proto/shims/npm

but with this:

{
  "scripts": {
    "a": "npm run b",
    "b": "whereis npm"
  },
  "volta": {
    "node": "24.0.0",
    "npm": "11.8.0"
  }
}

npm run a and npm run b both give

/home/owner/.proto/tools/node/24.0.0/bin/npm /home/owner/.proto/tools/npm/11.8.0/shims/npm /home/owner/.proto/shims/npm

It seems any time npm run is invoked it prepends the PATH with the builtin version. ~/.proto/tools/node/24.0.0/bin/npm is a shortcut that points to ../lib/node_modules/npm/bin/npm-cli.js. It could just point to ../../../../shims/npm maybe? So it's just pointing to the shim, no need to constantly change it, just set it up once during initial download. I tried that locally and it seems to work.

[TheJaredWilcurt]

How I think this could work:

1. Proto keeps a map of every npm version that shipped with Node. This is available here:
   • https://nodejs.org/download/release/index.json
2. Whenever Proto is resolving a Node version, it will also resolve the npm version from the map. If the user specifies a specific npm version instead, it just overrides the mapped one.

   // Some pseudo-code
   let nodeNpmVersionMap = {
     '25.6.0': '11.8.0',
     '25.5.0': '11.8.0',
     '25.4.0': '11.7.0',
     ...
   };
   let nodeVersion;
   let npmVersion;
   if (userPreference.node) {
     nodeVersion = userPreference.node; // '25.6'
     nodeVersion = resolveToExactVersion('node', nodeVersion); // '25.6.0'
     npmVersion = nodeNpmVersionMap[nodeVersion]; // '11.8.0'
   }
   if (userPreference.npm) {
     npmVersion = userPreference.npm; // '11.0'
     npmVersion = resolveToExactVersion('npm', npmVersion); // '11.0.0'
   }

3. Every time a Node version is downloaded (to ~/.proto/tools/node), it checks the local map to see what npm version it ships with, and it downloads that npm version (to ~/.proto/tools/npm). This keeps these versions separate.
4. It then replaces the ./bin/npm shortcut that the Node version ships with, with a shortcut to Proto's ~/.proto/shims/npm.
   • Maybe also do this any time someone runs a specific command, like proto upgrade, so people that upgraded don't need to redownload all their Node versions to get this fix. Any npm versions missing from ~/.proto/tools/npm will be downloaded automatically like usual on first use of a mapped Node version, as the npm version would be resolved now, just like if it was explicitly defined. Making this system more consistent.

This would fix my 3 points:

1. It would be impossible to be on the wrong Node/npm version.
2. devEngines would not refuse to run, because you're on the correct version
3. People aliasing npm commands can continue to do so, and will be on the correct version, no silent failing.

And it respects your 3 points:

1. The tools are more isolated. Without this fix, Node has npm intertangled in it's directory, rather than keeping it controlled separately like every other tool.
2. The symlink does not need constant deleting/unlinking/linking, it's a one-time process.
   • Done once during proto upgrade to apply this to all Node versions already downloaded
   • Done once on any individual Node version when first downloaded.
3. The user will always have the correct npm, npx, etc version that ships with that Node, unless they explicitly pick a different npm version, and then they will be on it, and cannot be on anything other than it.

[milesj]

I don't know, just seems like the fix is to ensure the PATH ordering is better. npm should come before node.

[TheJaredWilcurt]

Okay, how do we do that?

[milesj]

You're using proto activate right? I can control how PATH is built.

[TheJaredWilcurt]

I'm not, I did just run it but npm run a and npm run b are both doing the same as before (wrong version). I assume you meant you could possibly have that approach fix it. But it looks like this won't work for Windows cmd.exe according to the proto docs? Looks like it needs to be ran on shell startup, and that only Powershell supports that on Windows? I don't think this is as good of a solution then, since it would require more manual steps and not support all users, meaning you could still end up on the wrong version.

hmmm, according to this it can be done with CMD:

• https://superuser.com/questions/144347/is-there-windows-equivalent-to-the-bashrc-file-in-linux

So I guess maybe then, if it works

[milesj]

Those PATHs above would not be possible if you were only using shims.