[BUG] Version with v-prefix is incorrectly marked as valid

[LouisMT]

According to SemVer 2.0.0, a version like v1.2.3 is not valid (https://semver.org/#is-v123-a-semantic-version).

The library incorrectly marks a version like this as valid:

const semverValid = require('semver/functions/valid')

semverValid('v1.2.3')
// true

semverValid('v1.2.3', {loose: false})
// true

I understand that the v-prefix is often used to indicate that some string represents a version. However, when I explicitly want to check if a string is valid according to the SemVer spec, I expect the method to return false in this case, especially when I set the loose option to false.

A fix (or an option to be extra strict for backwards compatibility) would be appreciated!

[lukekarrys]

As a "fix" this would be a breaking change, so I would be against that. But I do think there is room for a feature that would allow for a more strict parsing according to the spec.

[ljharb]

The npm ecosystem doesn’t follow semver 2.0 - it follows 1.0, i believe - because version changes under v1 aren’t always breaking.

That said, i don’t think the v has ever been included according to the spec, but also, in the npm ecosystem it’s very often there. I don’t think there’d be any value in rejecting these.

[riderx]

@ljharb that not what is writed in the readme:
A "version" is described by the v2.0.0 specification found at https://semver.org/.
As @LouisMT i expected the validation to return false.
Especially when that is written in the readme one line after A leading "=" or "v" character is stripped off and ignored.

[ljharb]

Then i guess the docs are wrong.

[riderx]

@ljharb that what you believe, to me this package follow v2.0.0
According to this comment the npm ecosystem does too.
At least for Angular, react, node, typescript, svelte, nuxt, next, and most of the bigger packages.
it's seemed to me fairly legit to include this check in the validation by default in the next MAJOR version, and optional in the current one.

[ljharb]

That said, i don’t think the v has ever been included according to the spec, but also, in the npm ecosystem it’s very often there. I don’t think there’d be any value in rejecting these.

[riderx]

I see value in rejecting thoses.
Simple example:
I check SemVer in node ecosystem after these versions are uses in mobile (swift and android) where SemVer is implemented correctly and get refused.
SemVer should be implemented as the RFC for interoperability, not for NPM ecosystem.

[ljharb]

this package is explicitly and only for npm. it's not "the official semver package", it's "the npm ecosystem's official semver package"

[riderx]

This package is download more than 200,921,654 a week, there are a lot of chance that is used for standar SemVer and for NPM SemVer.
Implementation in Android and Swift have the name SemVer and implement the RFC not a language specific one.
if it's not "the official semver package", it could use a specific namespace like @npm/semver

[ljharb]

Everything on npm is node-specific by default, no scope is needed.

If you want something that can work in Swift, there should be a Swift package for it - which there is (https://github.com/ddddxxx/Semver, for example).

[riderx]

I agree for all packages who are 100% node-specific.
Sadly, versioning is in use everywhere.
Semver package is a parser for something who is notnode-specific.

Any parser (HTML, CSS, MARKDOWN) in NPM follow the RFC as much as they can.

We try to stop having browsers interpreting the JS differently, and follow the RFC for interoperability.
Package should do it too when RFC exist.

[ljharb]

Browsers have nothing to do with this - this package is for npm's semver implementation only. If you're using it for non-npm semver, you're misusing it.

[riderx]

I'm talking about interoperability and use example like Browsers and JS story to find a common ground where we can understand each others.

I use this package in a CLI who is coded in JS, but made for other usage than node.

I misusing it for sure, the namespace, the README let me think it was a generic package following a generic convention.

If you believe i'm the only one who going to think that, you're missing some perspectives. :/

[ljharb]

The repo is named “npm/node-semver” and it’s a node package published on npm, I’m not sure how much clearer it could be ¯\_(ツ)_/¯