Allow packages to declare a schema for what kind of versioning system it uses (Allow use of non-SemVer)

[Nixinova]

What is the problem this feature will solve?

Many popular projects do not use SemVer. Take Microsoft/TypeScript (microsoft/TypeScript#14116) or jashkenas's packages (jashkenas/underscore#1684). These package maintainers do not follow the implicit contract of using SemVer, sometimes due to fundamental opposition to SemVer itself (https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e).
This leads to friction among users:

I'm concerned that not following semver is creating unnecessary friction for TypeScript consumers who are opted in to having their builds broken whenever TypeScript releases a minor version as npm locks down to only major versions by default.
– microsoft/TypeScript#14116 (comment)

The obvious solution is just to go "not Node's problem - they should be using Semver!" - but that's not going to happen.
We as package consumers are stuck with having to be aware that many critical packages do not follow the expected semantics of SemVer.

What is the feature you are proposing to solve the problem?

Therefore, Node should have a built-in solution for allowing package maintainers to decouple themselves from SemVer.

My proposal is to have an entry in package.json that defines what Versioning schema the package shall use.

I have a drafted schema definition file (schema.json) that defines aspects such segment types, ordering, and which digit increments represent breaking changes.
The default position of package.json would obviously be the use of SemVer, which I have a drafted schema for (semver.schema.json).
These drafted schemas could be adapted and maintained by Node.js to allow an official API for package maintainers to create their own versioning schemas to use in their projects.

This versioning schema would then be checked when installing a version from a range declared in the package.json (like package@^2.3.0), where the semantics for ^ are "the highest non-breaking version after or including 2.3.0", with what counts as "non-breaking" defined by the provided schema.

Real world example:

If Microsoft declares that for their typescript package, both the first and second digits represent breaking changes (declared using an in-house versioning schema linked to from package.json) -- then installing ^5.2 would not install version 5.5.2 (as expected from SemVer semantics), but only install the highest non-breaking version (which would be something like 5.2.3).

What alternatives have you considered?

"Just use SemVer", but this is not a realistic outcome as us consumers have no way of forcing maintainers like Microsoft to switch from their 'marketing versioning' to use SemVer.

---

This is similar in reason to this stale/unseen proposal npm/npm#19231 but goes quite further beyond by allowing the entire semantics of a version to be user-defined instead of just saying which digit is the breaking digit.
Having this functionality be more complicated than just setting a string is better as it would discourage usage of non-semver versioning - this proposal is for package managers that really, really, really don't want to use semver for some reason or another.

---

If this is more suited for the npm/cli repo then please transfer it there and if it is more suitable as a Github Discussion please make it one

[tniessen]

If this is more suited for the npm/cli repo then please transfer it there

Node.js itself follows semantic versioning, but how npm handles versioning of dependencies is entirely up to npm (as well as other package managers). We cannot transfer issues to repositories that we do not own.

[tniessen]

(It might be simplest to just lock down the versions of those dependencies exactly and to have your own update logic that deviates from semver.)

[Nixinova]

(It might be simplest to just lock down the versions of those dependencies exactly and to have your own update logic that deviates from semver.)

My point isthat -- even though this is kind-of easy to work around as a user -- when one package installed using vanilla npm install X stops following semver for whatever, a simple npm update will break projects. This means that the solution has to come from the package definition (allowing people to define what system of versioning they use) rather than any end-user consumers.

We cannot transfer issues to repositories that we do not own.

Ah okay, thought there'd be some cross-over of maintainers. I can manually move this over to npm/cli if a change to package.json changes is more suited there - is it?

[Nixinova]

Also, the drafted schema as it stands would allow for !=3 digits in a version number. Would that break any part of Node.js?

[tniessen]

My point isthat -- even though this is kind-of easy to work around as a user -- when one package installed using vanilla npm install X stops following semver for whatever, a simple npm update will break projects.

FWIW, the main argument against semver seems to be "every change can be a breaking change in JavaScript", or at least this is expressed in both threads you referenced (see microsoft/TypeScript#14116 (comment) and jashkenas/backbone#2888 (comment)). If this means that a change in any part of the version number indicates a potentially breaking change, then it seems that this will have the same effect as locking the version numbers down to exact versions. (And even for packages that do follow semver, semver-minor updates can break things.)

Also, the drafted schema as it stands would allow for !=3 digits in a version number. Would that break any part of Node.js?

No, Node.js has nothing to do with npm versioning and doesn't read the "version" field at all, as far as I am aware.

I can manually move this over to npm/cli if a change to package.json changes is more suited there - is it?

I don't know where the npm team is having such discussions, but it certainly seems more appropriate for their spaces than ours, so I will close this issue.

[Nixinova]

Thanks for the info. Moved this to npm/rfcs#794 👍