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

[FEATURE] normalize x, x@, x@* #45

Closed
isaacs opened this issue Nov 9, 2019 · 2 comments
Closed

[FEATURE] normalize x, x@, x@* #45

isaacs opened this issue Nov 9, 2019 · 2 comments
Labels
Enhancement new feature or improvement

Comments

@isaacs
Copy link
Contributor

isaacs commented Nov 9, 2019

What / Why

These things are all effectively the same:

  • name
  • name@
  • name@*

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.

When

  1. npa('name@')
  2. npa('name')
  3. npa('name@*')

Current Behavior

1 and 2 parse as:

Result {
  type: 'tag',
  registry: true,
  name: 'name',
  rawSpec: '',
  fetchSpec: 'latest'
}

3 parses as:

> npa('name@*')
Result {
  type: 'range',
  rawSpec: '*',
  fetchSpec: '*',
}

Expected Behavior

  • All 3 should parse the same, like (3) above. Effectively, a '' 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.

@darcyclarke darcyclarke added the Enhancement new feature or improvement label Jul 28, 2022
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
@wraithgar
Copy link
Member

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
@wraithgar
Copy link
Member

Yay

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement new feature or improvement
Projects
None yet
Development

No branches or pull requests

3 participants