What / Why
These things are all effectively the same:
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
npa('name@')
npa('name')
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.
What / Why
These things are all effectively the same:
Right now,
name@andnameare 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@latestshould 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 iflatestwas 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.