-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
[BUG] npx does not fetch latest possible semvar match #7838
Comments
I am getting expected behaviour ~/workarea/rep/test $ npx -ddd momentic@1.0.12 init
Need to install the following packages:
momentic@1.0.12
Ok to proceed? (y) y ~/workarea/rep/test $ npx momentic@^1 init
Need to install the following packages:
momentic@1.0.13
Ok to proceed? (y) |
you don't need to do that; do |
We are aware of that, but we don't want to use Besides, it seems like a bug that this behavior is a) non-deterministic across machines and b) different from what is advertised in the official docs:
|
@jeff-an what's the output of |
I put it in the environment section: version: 10.9.0 npm config: auto-install-peers = true
public-hoist-pattern = ["*eslint-plugin*","*prisma*","*bull*"] |
|
What constitutes a local project or workspace? We have not installed this package ( |
Project with package.json and dependencies installed or this cli tool installed globally. My output ~/workarea/rep $ node -v
v20.9.0
~/workarea/rep $ npm -v
10.9.0
~/workarea/rep $ npx -v
10.9.0
~/workarea/rep $ npx turbo@2.1.0 -V
Need to install the following packages:
turbo@2.1.0
Ok to proceed? (y)
ERROR unexpected argument '-V' found
tip: to pass '-V' as a value, use '-- -V'
Usage: turbo [OPTIONS] [COMMAND]
For more information, try '--help'.
~/workarea/rep $ npx turbo@^2 -V
Need to install the following packages:
turbo@2.2.3
Ok to proceed? (y)
ERROR unexpected argument '-V' found
tip: to pass '-V' as a value, use '-- -V'
Usage: turbo [OPTIONS] [COMMAND]
For more information, try '--help'.
~/workarea/rep $ npm config ls
; "project" config from /Users/milaninfy/workarea/rep/.npmrc
auto-install-peers = true
public-hoist-pattern = "[\"*eslint-plugin*\",\"*prisma*\",\"*bull*\"]"
~/workarea/rep $
|
you can use command this way |
any other information I can provide here @milaninfy ? only thing that seems to definitively fix the issue for the next invocation is |
friendly bump... |
Some possibly related weird behavior. Here |
These are different entries in the npx cache. The npx cache is indexed by the entire package arg. Within a given npx cache entry, if the spec (everything after the @) is a range it will look to see if a newer version exists. It will not consider other entries in its cache. In order to get the behavior you want you need to give npx the same package arg each time. If you want latest, just give it the package name with no spec. If you want a version, use that version every time. You can also use a dist-tag. |
Thanks for the response! A few questions:
|
The entire argument as given on the cli is used. If multiple packages are given (i.e. with the No cli commands are going to be able to clear the npx cache. It's isolated from npm's normal cache. There is also no way to inspect the npx cache. It's located at |
OK, but that doesn't seem to explain the original issue, where running
|
It does for me locally. We're back to the point where we can't reproduce this locally $ npx momentic@1.0.12 init
Need to install the following packages:
momentic@1.0.12
Ok to proceed? (y)
Welcome to the Momentic project setup wizard! $ npx momentic@^1 init
Need to install the following packages:
momentic@1.0.37
Ok to proceed? (y) n |
Yes, we know it works on some people's machines and not on others'. But as you can see from earlier in this thread, I've provided logs and screenshots from multiple sources that say this doesn't work (I can still in fact reproduce on my laptop). So is there some additional information we can provide to narrow down the problem? Or if you want to point us to where this code is, we're happy to look ourselves as well. |
when using a range, npm is supposed to use whatever it finds, but ONLY if it's present in local or global. The npx cache inspection is supposed to look only at the resolved version. This line is likely where the bug is. It's supposed to make npm NOT match by range or tag if we're checking the npx cache, and fall through to an identical version |
The behavior requested by @jeff-an is the opposite of the behavior I would expect. The npm package json dependencies documentation says
and the npm node-semver package's section on caret ranges says
The italicized emphasis is mine in both quotes. Based on the documentation, I would expect Neither of the documentation linked above discusses what version to prefer when provided with a range. I think that might be the source of the relevant nuance here. For example, if I have this in a "dependencies": {
"express": "^4"
} and express is not installed, the Given that
and states
It goes on to say, however, that
I think this part of the specification (documentation, in this case) violates semver. Assuming the "specifier" can be any valid semver, including a range, then I think this statement is at best incomplete/confusing, and at worst in direct conflict. I would expect it to use any local package that matches the supplied semver specifier. I would not expect it to install a later version of the package. I could easily see how that behavior would be considered a feature though, since otherwise you may end up "stuck" on an old version as time goes on. But I also feel it is counterintuitive and confusing. To add to the confusion, one of the top search results is a stack overflow answer that incorrectly states
I don't have any context as to why npx behaves this way, so forgive my ignorance. But hey, sometimes lack of context can be an advantage. If the behavior I propose is the expected behavior, that would potentially make the current behavior a bug. I came across this issue in the context of npx attempting to install the latest version of a package even though both the |
I would be totally OK with the behaviour described by @kyle-blair as well, as long as But more importantly it seems like today neither behaviour happens reliably which is the worst of both worlds in my opinion. |
To summarize:
|
Yes, this is the expected behavior everywhere else but the npx cache itself. The user does not have any direct access to that cache, so it needs to be able to update if a newer version is available. A fix for this should not alter the existing behavior for packages found in the local package, or installed globally. I still think a fix for this should fetch the highest matching semver version in the absence of that package anywhere except the npx cache. |
Is there an existing issue for this?
This issue exists in the latest npm version
Current Behavior
When using the syntax
npx <package>@<semvar> <command>
,npx
is always using a local cached version instead of fetching the latest available version that falls within the semvar from the npm registry and prompting for an upgrade.Running
npm cache clean --force
does not seem to help.The issue only seems to be reproducible on some machines. One user even reported that with momentic@1.0.12 installed locally,
npx momentic^1
was still invoking1.0.11
instead of the newer version.Expected Behavior
I expect
npx
to issue a prompt like the one below:rather than proceeding with the locally cached version of momentic@1.0.12, for example.
Steps To Reproduce
npx momentic@1.0.12 init
and accept the install prompt. Ignore the output of the program (the program in this case doesn't matter and can be substituted with any other).npx momentic@^1 init
. This should be expected to prompt to install1.0.13
or whatever the latest version is. However, it does not and instead prints the same output as step 1.Screenshot of what I mean on the
turbo
repo (the latestturbo
version is2.1.3
at time of writing):Environment
I confirmed that my npx path is fixed and set to:
The text was updated successfully, but these errors were encountered: