feat: allow strict semver check

[riderx]

The Current Implementation does not follow SemVer v2 as stated in the doc.
This allows following the spec by making leading v as invalid with an option named "strict".

I'm open to renaming it if needed.

References

Related to #376
and #376
and PR: #476 who was rejected.

[wraithgar]

This introduces a bit of a confusing paradigm here now. We already have the loose option, which defaults to true. I think adding a strict config that now solely interacts with this one part of parsing is confusing and incorrect. Folks would assume (correctly I would say) that these configs are reflections of each other and should act as such.

This is a rather subtle and complex problem to solve unfortunately. The v-prefixed version is likely here to say based on how disruptive removing it would be.

I think there is still merit in having a way to tell this package to ignore that vestigial support, but I don't think adding a strict option to the constructor is the full solution. Also I unfortunately don't have any good input on what the full solution is, which I know is frustrating. More discussion is needed here, and this PR is a good place to have it for now.

[riderx]

@wraithgar thanks for the prompt reply, I see what you mean and you are right.
I think I could do a SemVer2 option and this will set the loose to false then.

Do you think it could less confusing and valid ?

[ljharb]

No, because semver 2 doesn't have ranges in it either, and its description of v0 versions doesn't match npm's. Trying to match semver v2 isn't worth the effort - at some point there'll be a semver v3 that matches npm, and npm won't have to change anything.

[riderx]

@ljharb I'm just trying to be able to use validate from this package and make it closer to the spec, each step closer should be seen as a success.
If the SPEC bothers you, let's open an issue in it https://github.com/semver/semver/issues or maybe fork it and create NPM SemVer spec to lead this change.
Currently, this package misleads people thinking it follows the spec by linking it in the README. Where it don't
Any improvement will misslead less than now

[ljharb]

I've discussed it with the spec maintainers and there's PRs open for much of what I discussed.

npm's flavor of semver is much more valuable and widespread than the spec itself - specs should document reality, not dictate it.

[mbtools]

Close to no one is using the v prefix anyway (see here). Removing the prefix in next major won't be disruptive.

[ljharb]

It's still of little value to remove imo, given that https://semver.org/#is-v123-a-semantic-version allows it.

[riderx]

It does not “ Example: git tag v1.2.3 -m "Release version 1.2.3", in which case “v1.2.3” is a tag name and the semantic version is “1.2.3”.” as you can see. And none of any others package i tried who implement the spec of Semver in others languages /platform allow it.
for my experience, java, kotlin, swift, deno

[ljharb]

That's an example. fwiw I think it'd be fine to add an option to disallow the v.

[wraithgar]

Close to no one is using the v prefix anyway (see here). Removing the prefix in next major won't be disruptive.

The primary use case for the v-prefix is in git tags. This v is a config item but most folks leave it as a default https://github.com/npm/cli/blob/5b858c6b2c275f0e670e09c52de5b931936d6e07/workspaces/libnpmversion/lib/retrieve-tag.js#L8

This explicitly asks for a loose parsing so relegating the parsing of this kind of string to "loose" parsing only wouldn't break npm specifically. I don't know of any other use cases that rely on this v.

A more proper way of doing this would be taking the configured tag prefix into account, only looking at tags that match, and stripping it before passing it to semver.parse.

We are extremely hesitant to cut a new semver major release of this module however. It is one of (if not the) most commonly downloaded package out there, and we want to move very slowly and deliberately here.

I think this is a worthwhile conversation still, but again don't want to rush or make hasty decisions.

[riderx]

I agree i do see the prefix used in git tag a lot, but not in package itself.
a real data who could help would be to find usage of the lib in code and see how many time it’s used to parse git tag, but it seems impossible mission to properly do it. Maybe @mbtools you know some magic for this?
To me the best way would be to release a sub package, like semver/strict (if we can get the stats otherwise a different name), and see if over time the stats lean to it with of course a clear incentive in the readme.
if that the case then we know that the direction the community expects to package to go.
Data would be better than any conversation to me :)

[mbtools]

dear wizard of almighty ai, please scan 1/2 billion GH repos and 50 mill on gitlab for semver parsing a git tag 😄