Repository navigation
[BUG] limit version prefix to optional v #691
Description
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
The following "ranges" are currently considered valid: > v=1.2.3, > vvv1.2.3, > v==1.2.3, > v=vv==v1.x
The validation is not strict enough and allows =, v=, and nonsensical prefixes as well.
Expected Behavior
With next major semver, the version prefix should be limited to a single, optional v. Other prefixes shall not be permitted anymore.
Suggested change:
// createToken('LOOSEPLAIN', `[v=\\s]*${src[t.MAINVERSIONLOOSE] // old
createToken('LOOSEPLAIN', `v?\\s*${src[t.MAINVERSIONLOOSE] // new
// createToken('XRANGEPLAIN', `[v=\\s]*(${src[t.XRANGEIDENTIFIER]})` + // old
createToken('XRANGEPLAIN', `v?(${src[t.XRANGEIDENTIFIER]})` +// new
// createToken('XRANGEPLAINLOOSE', `[v=\\s]*(${src[t.XRANGEIDENTIFIERLOOSE]})` + // old
createToken('XRANGEPLAINLOOSE', `v?\\s*(${src[t.XRANGEIDENTIFIERLOOSE]})` + // newSteps To Reproduce
validRange('> v=1.2.3') Environment
- node-semver: 7.6.0
Activity
wraithgar commentedon Mar 20, 2024
Added this to #501
mbtools commentedon Mar 22, 2024
I have done some analysis of all versions, dependencies and engine ranges used in the top 5200 npm
package.jsonfiles:The use of
vorv=prefixes is extremely rare. It's only 2 cases (which could be tags and valid).I would suggest to put up a deprecation notice of these semver v1 notations and then completely stick to semver v2 (i.e. no prefixes, not even av) with the next major.ljharb commentedon Mar 22, 2024
why even bother removing the
v? there's nothing conceptually wrong with it; npm doesn't comply with semver v2 anyways; and https://semver.org/#is-v123-a-semantic-version supports its use as an optional prefix.mbtools commentedon Mar 27, 2024
Agree. Removing
vwon't make a difference. Stats are interesting nevertheless 😃