Skip to content
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

fix: standardize x x@ and x@* #97

Merged
merged 1 commit into from
Oct 18, 2022
Merged

fix: standardize x x@ and x@* #97

merged 1 commit into from
Oct 18, 2022

Conversation

wraithgar
Copy link
Member

@wraithgar wraithgar commented 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

@wraithgar wraithgar requested a review from a team as a code owner September 1, 2022 16:04
@wraithgar wraithgar force-pushed the gar/normalize-defaults branch from b0119a0 to 32a88d5 Compare September 1, 2022 16:07
@ljharb
Copy link
Contributor

ljharb commented Sep 1, 2022

Will this have any implications on npm install foo itself? Ideally places that currently look for latest wouldn't start looking for * (because that seems like it would break use cases where i've published v1.0.1 with a bug, so i set latest to v1.0.0 while i work on a v1.0.2, because i want to push people away from v1.0.1)

@wraithgar
Copy link
Member Author

Nope, check out the rest of the comment.

npm (via npm-pick-manifest) will prefer its default tag if given a range that includes it

@wraithgar wraithgar marked this pull request as draft September 28, 2022 19:43
@wraithgar
Copy link
Member Author

Converting to draft while I do the next phase, which is to npm link this into the cli and smoke test it.

@wraithgar wraithgar force-pushed the gar/normalize-defaults branch from 32a88d5 to f535d66 Compare September 29, 2022 18:01
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BREAKING CHANGE(spec): Normalize x, x@ & x@*
3 participants