[BUG] npx won't execute the latest version of a package

[nullromo]

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

I tried running npx ts-node@latest, but npx decided to execute a version of ts-node that is not the latest.

$ rm -rf ~/.npm
$ node --version
v18.7.0
$ npm --version
8.16.0
$ npx ts-node --version
v9.1.1
$ npx ts-node@latest --version
Need to install the following packages:
  ts-node@10.9.1
Ok to proceed? (y) y
v9.1.1

It even asks me if I want to install version 10.9.1, but then it runs version 9.1.1 anyway 😕

Expected Behavior

I expect npx <package>@latest to always run the latest version of a package.

Similarly, I expect npx <package>@<version> to always run the specified version. For example, npx ts-node@10 should run ts-node version 10

Steps To Reproduce

1. Update node and npm to the latest versions.
2. Try running npx ts-node@latest --version.
3. It runs an older version
4. Try deleting ~/.npm; same problem.
5. Try globally uninstalling ts-node; same problem.
6. Try locally uninstalling ts-node; same problem.

Environment

• npm: 8.16.0
• Node.js: 18.7.0
• OS Name: WSL

; node bin location = /usr/local/bin/node
; node version = v18.7.0
; npm local prefix = /home/kkovacs/oss_97542
; npm version = 8.16.0
; cwd = /home/kkovacs/oss_97542
; HOME = /home/kkovacs
; Run `npm config ls -l` to show all defaults.

[nullromo]

I just learned about npx which.

$ npx which ts-node
/home/kkovacs/oss_97542/node_modules/.bin/ts-node

So I found out that npx was actually using my local version of ts-node for some reason. Apparently both ts-node versions 9 and 10 were sub-dependencies in the project.

After I discovered that, I found out that I have a subproject which had a dev dependency of ts-node version 9 (not the latest). After updating that one to version 10, npm list --depth=1 shows all the ts-node dependencies at the latest version. Now npx runs the right version.

Again, it's still a bug that npx ts-node@latest doesn't run the latest version, but now I have a better understanding of what happened. I had a non-latest version installed locally buried inside node_modules in addition to the latest version installed locally and also buried inside node_modues. For some reason, npx chose to execute the non-latest one no matter what I specified.

[wraithgar]

npx looks in your local tree to see if the package you asked for is there, if so it runs the bin for it. If you have two different versions in your local tree this can mean npm runs whichever of the two "won" and put itself in the bin folder. There's not a lot npm can do about this, as there is no mechanism for discovering which version of the package "won". The solution you came up with was correct: to fix your local tree.

Once #5291 is merged and released you should be able to also specify a --prefix that points to an empty directory to be sure npm ignores any tree it finds in the current working directory.

[nullromo]

What you said makes sense. The part that doesn't make sense is why npx allows @<version> if it's not even going to use that part.

If it's not using that version specifier at all, then I at least expect some kind of warning like "you have specified a specific package version, but npx cannot run specific versions of packages"

[wraithgar]

npx doesn't ignore the version, it looks for anything in your local tree that matches the spec you give it, version, tag, or range. What it can't do is work backwards from the situation where two versions are in your tree competing for the linked bin, and knowing which one won.

[nullromo]

Thank you for explaining; I appreciate it. So that I understand better, is this right?

1. v9 and v10 are installed locally and for one reason or another v9 "wins" meaning that the bin version points to v9 code.
2. I invoke npx specifying @latest.
3. npx determines that the latest version is v10.
4. npx sees that I "already have v10 installed locally" (which is pseudo-true) so it tries to execute from the bin without necessarily knowing that the bin version is actually pointing to v9.
5. v9 executes.

[wraithgar]

Yes that's right.

[ljharb]

could npx not execute the package.json bin from v10’s dir, rather than from node_modules/.bin?

[wraithgar]

Nope because it's not a bin there, it's just a reference to what will become the bin when bin-links does its thing. This is the same reason we have to "install" a local directory reference when running npx ..

[ljharb]

ahh k, so unless we had a bin-links-processed version of every package that wouldn’t be a reliable option.