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.
– https://github.com/microsoft/TypeScript/issues/14116#issuecomment-292387172
The obvious solution is just to go "not npn'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, npm 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 npm 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 https://github.com/npm/npm/issues/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.
Moved from https://github.com/nodejs/node/issues/54016
What is the problem this feature will solve?
Many popular projects do not use SemVer. Take Microsoft/TypeScript (https://github.com/microsoft/TypeScript/issues/14116) or jashkenas's packages (https://github.com/jashkenas/underscore/issues/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:
The obvious solution is just to go "not npn'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, npm should have a built-in solution for allowing package maintainers to decouple themselves from SemVer.
My proposal is to have an entry in
package.jsonthat 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 npm 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
typescriptpackage, both the first and second digits represent breaking changes (declared using an in-house versioning schema linked to from package.json) -- then installing^5.2would not install version5.5.2(as expected from SemVer semantics), but only install the highest non-breaking version (which would be something like5.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 https://github.com/npm/npm/issues/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.