-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] normalize x, x@, x@* #45
Labels
Enhancement
new feature or improvement
Comments
32 tasks
wraithgar
added a commit
that referenced
this issue
Sep 1, 2022
BREAKING CHANGE: `x` and `x@` now return the same spec as `x@*` From #45: Right now, `name@` and `name` are parsed with `{type:'tag', fetchSpec: 'latest'}`, but `name@*` is parsed as `{type: 'range'}`. But since `''` is a valid semver range, it should be parsed the same as `*`. This also saves npm-package-arg from guessing the default tag, which currently poses some semantic hazards. npm (via npm-pick-manifest) will prefer its default tag if given a range that includes it. But `name@latest` should always and only resolve to that specific version in the dist-tags. So npm-pick-manifest and pacote have to detect this and do some extra work to figure out if `latest` was actually specified or just guessed as a default.
wraithgar
added a commit
that referenced
this issue
Sep 1, 2022
BREAKING CHANGE: `x` and `x@` now return the same spec as `x@*` From #45: Right now, `name@` and `name` are parsed with `{type:'tag', fetchSpec: 'latest'}`, but `name@*` is parsed as `{type: 'range'}`. But since `''` is a valid semver range, it should be parsed the same as `*`. This also saves npm-package-arg from guessing the default tag, which currently poses some semantic hazards. npm (via npm-pick-manifest) will prefer its default tag if given a range that includes it. But `name@latest` should always and only resolve to that specific version in the dist-tags. So npm-pick-manifest and pacote have to detect this and do some extra work to figure out if `latest` was actually specified or just guessed as a default. Closes npm/statusboard#460
Erring on the side of caution and making it a major for this package, and introducing it in npm9. |
wraithgar
added a commit
that referenced
this issue
Sep 29, 2022
BREAKING CHANGE: `x` and `x@` now return the same spec as `x@*` From #45: Right now, `name@` and `name` are parsed with `{type:'tag', fetchSpec: 'latest'}`, but `name@*` is parsed as `{type: 'range'}`. But since `''` is a valid semver range, it should be parsed the same as `*`. This also saves npm-package-arg from guessing the default tag, which currently poses some semantic hazards. npm (via npm-pick-manifest) will prefer its default tag if given a range that includes it. But `name@latest` should always and only resolve to that specific version in the dist-tags. So npm-pick-manifest and pacote have to detect this and do some extra work to figure out if `latest` was actually specified or just guessed as a default. Closes npm/statusboard#460
wraithgar
added a commit
that referenced
this issue
Oct 12, 2022
BREAKING CHANGE: `x` and `x@` now return the same spec as `x@*` From #45: Right now, `name@` and `name` are parsed with `{type:'tag', fetchSpec: 'latest'}`, but `name@*` is parsed as `{type: 'range'}`. But since `''` is a valid semver range, it should be parsed the same as `*`. This also saves npm-package-arg from guessing the default tag, which currently poses some semantic hazards. npm (via npm-pick-manifest) will prefer its default tag if given a range that includes it. But `name@latest` should always and only resolve to that specific version in the dist-tags. So npm-pick-manifest and pacote have to detect this and do some extra work to figure out if `latest` was actually specified or just guessed as a default. Closes npm/statusboard#460
wraithgar
added a commit
that referenced
this issue
Oct 18, 2022
BREAKING CHANGE: `x` and `x@` now return the same spec as `x@*` From #45: Right now, `name@` and `name` are parsed with `{type:'tag', fetchSpec: 'latest'}`, but `name@*` is parsed as `{type: 'range'}`. But since `''` is a valid semver range, it should be parsed the same as `*`. This also saves npm-package-arg from guessing the default tag, which currently poses some semantic hazards. npm (via npm-pick-manifest) will prefer its default tag if given a range that includes it. But `name@latest` should always and only resolve to that specific version in the dist-tags. So npm-pick-manifest and pacote have to detect this and do some extra work to figure out if `latest` was actually specified or just guessed as a default. Closes npm/statusboard#460
Yay |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What / Why
These things are all effectively the same:
Right now,
name@
andname
are parsed with{type:'tag', fetchSpec: 'latest'}
, butname@*
is parsed as{type: 'range'}
. But since''
is a valid semver range, it should be parsed the same as*
.This also saves npm-package-arg from guessing the default tag, which currently poses some semantic hazards. npm (via npm-pick-manifest) will prefer its default tag if given a range that includes it. But
name@latest
should always and only resolve to that specific version in the dist-tags. So npm-pick-manifest and pacote have to detect this and do some extra work to figure out iflatest
was actually specified or just guessed as a default.When
npa('name@')
npa('name')
npa('name@*')
Current Behavior
1 and 2 parse as:
3 parses as:
Expected Behavior
''
spec should be changned to'*'
and interpreted accordingly..I don't think this is a breaking change, since it won't require any users to change their code, but it will make some workaround code paths become dead, which will fail some coverage tests. Not sure if this means it's a semver patch or major, worth discussing.
The text was updated successfully, but these errors were encountered: