[BUG] npx resolving wrong binary when using a workspace

[niklasholm]

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

Current Behavior

When using a multi-workspace monorepo, and the same package is present in both the root and a workspace, but with different versions, npx without a --package or --call argument will resolve the package installed in the root rather than the one in the workspace when using the --workspace option.

Expected Behavior

npx should resolve and execute the package installed in the specified workspace if present.

Steps To Reproduce

1. Setup steps (output omitted)

$ npm init --yes
...
$ npm init -w app --yes
...
$ npm install --save-dev 'eslint@^8'
...
$ npm install -w app --save-dev 'eslint@^7'
...

2. Check versions of installed packages without npx

$ ./node_modules/.bin/eslint --version
v8.48.0
$ ./app/node_modules/.bin/eslint --version
v7.32.0

3. Run the same command with npx

$ npx --no -- eslint --version
v8.48.0   # Correct
$ npx --no -w app -- eslint --version
v8.48.0   # Incorrect!
$ npx --no -w app --package=eslint -- eslint --version
v7.32.0   # Correct
$ npx --no -w app -c 'eslint --version'
v7.32.0   # Correct

As shown above when using the --package and/or --call forms of the command it resolves the correct version of eslint but not with only positional arguments, even though they should be equivalent since the package name and binary name is the same,

Environment

• npm: 10.0.0
• Node.js: 18.17.1
• OS Name: Windows 10 22H2
• System Model Name: ThinkPad T480 20L5
• npm config:

; "builtin" config from C:\Users\nikho\AppData\Roaming\npm\node_modules\npm\npmrc

prefix = "C:\\Users\\nikho\\AppData\\Roaming\\npm"

; node bin location = C:\Program Files\nodejs\node.exe
; node version = v18.17.1
; npm local prefix = C:\Users\nikho\npx-test
; npm version = 10.0.0
; cwd = C:\Users\nikho\npx-test
; HOME = C:\Users\nikho
; Run `npm config ls -l` to show all defaults.

[lukekarrys]

Just a note that I confirmed this bug on both npm 9 and 10.

[siemhesda]

The behavior you described does not seem to be a bug in npx, looks more like an intended design based on how npx resolves and executes packages.

When you provide the package name explicitly using the --package option, npx knows exactly which package to execute, and it doesn't rely on the local context or the package.json file to determine the package.

If you want to ensure that a specific version of a package is used consistently, you can always use the --package option as you did in your example:

$ npx --no -w app --package=eslint -- eslint --version

This way, you explicitly specify the package to use, and you have control over the version. This can help ensure consistent behavior, especially if you have multiple versions of a package installed in different locations.

I don't think it is a bug but rather a feature of npx to provide flexibility in resolving and executing packages. Using the --package option is a reliable way to ensure a specific version is used.

npx will try to execute the locally installed eslint package, and it will look at the bin field in the package.json file of the project to determine which binary to run. If there is no locally installed eslint package, it will fall back to using the globally installed eslint package.

However, when you run npx with --package, it explicitly specifies which package to use, and it doesn't rely on the locally installed package.

[niklasholm]

@siemhesda Your explanation does not make any sense when considering the documentation, which states:

To run a binary other than the named binary, specify one or more --package options, which will prevent npm from inferring the package from the first command argument.

Implying that when --package is omitted, the package name is inferred from the command name, which is in this case ("eslint") is identical to the package name, so determining the package name to be "eslint" should be trivial, and --package should make no difference, especially in regards to which locally installed version of "eslint" is used (workspace or workspace root).

I'm not sure the situation you're describing is relevant since you're talking about locally vs globally installed, whereas this issue is about locally installed in workspace vs workspace root.

If this is indeed intentional behavior, then the documentation should be updated to reflect this. I challenge you to explain this logic in such a way that it makes sense to the regular user, because I cannot. If I've missed something, please help me out and point to the relevant paragraph for me.

[wraithgar]

#6973 fixes this and another bug found while working on this one. npm will now look in the workspace for both the bin entry and the installed dependencies.

[niklasholm]

@wraithgar Thank you!