Can typescript please follow semver? So we can know when an upgrade is minor/major/patch ?

[nojvek]

Search Terms

semver, breaking changes, semantic versioning

Suggestion

I realized 4.0.0 isn't a breaking change. Typescript versions aren't like other node package versions. Now sure how they increment and who decides version numbers.

Could we adopt semver ? It makes it super easy to know whether a version upgrade is a breaking change, a new additional feature or just a small bug fix.

As a package consumer, knowing the answers to those questions is important and since TS doesn't follow semver it means as an author, I have to manually fiddle through release notes to figure things out.

https://docs.npmjs.com/about-semantic-versioning

By default npm installs with '^x.y.z', which means latest package with same major version, so minor releases are allowed.

By releasing with semver, it plays well with rest of npm ecosystem.

Use Cases

Have a sane dev life.

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This feature would agree with the rest of TypeScript's Design Goals.

[kitsonk]

Duplicate of #14116

Please don't open duplicate issues.

[trevyn]

@kitsonk @RyanCavanaugh #14116 is now locked, which means that we can't provide +1's, which means Microsoft is unable to measure community feedback on this issue.

How should we proceed without opening duplicate issues, if we wish to communicate that this issue continues to impact us?

[calidion]

semver has been proved totally wrong and misleading.
node.js or any other communities should be convinced and never mention it again.

even node.js itself uses lts releases and development release to avoid semver and npm's version range problem.

[trevyn]

@calidion Node follows semver (in addition to its own LTS and even/odd semantics), so I'm unclear as to your argument. Could you provide links to any supporting articles or posts?

[calidion]

@trevyn

LTS is a way to reduce the pace of the problem that semver and npm version range introduced.
semver is only correct on theory not in reality.
even people want to obey the rules semver set up, they will inevitably break them in one way or another.
npm version range amplifies such instability makes node modules the black hole.

so currently npm provides package-lock.json to lock all versions as rescue.
it means that versions are stored precisely in package-lock.json, no range any more.
why? because version range can be constantly broken.
That is to say, semver's promise can not be kept in reality.
Every package maintainer can be wrong in one way or another to break the compatibility the semver promised.
rust's cargo locks versions for every package, so can the rust projects keep stable.

semver is misleading in that versions should show evolution in its architecture not showing if it is compatible or not,
and it is also misleading in encouraging version updates.

Version updates should be discouraged if your projects are comfortable with current versions.

Every version update will lead to new works and costs, it is a waste of time and efforts.

[calidion]

If versions are used to show compatibility, they needs only one dot:
INCOMPATIBLE.COMPATIBLE
And no one can promise his patch will definitely be compatible.

[kokushkin]

Would like to see it. If it was (and still) an initial development then authors obviously missed the first 0 in the 0.x.y. You are a package in the npm after all, there are tools that don't understand the "uniqueness" of typescript in versioning.

[tubbo]

semver has been proved totally wrong and misleading.
node.js or any other communities should be convinced and never mention it again.

Honestly, I think NodeJS and NPM's total misuse of semver is the real problem. Most RubyGems use semver and don't have this problem, because Bundler uses tilde dependency constraints rather than caret by default. The fact that Yarn/NPM assume you want the highest version of a package that's not a new major by default is to me the biggest disappointment.

When entire services spring up around the problem that your package manager causes, you know you screwed something up.

[calidion]

@tubbo

That is because Semver think the consistancy between patches/minor changes can be very easily kept by the developers with every update.
Npm's version range is just following the wrong assumption introduced by semver.

[thw0rted]

I don't expect anybody from the team is still following this issue, but I'd like to add a data point, and maybe somebody will notice it eventually.

It looks like #14116 was closed with the idea that users writing TS code "can" break their build with any upgrade -- fixing an incorrect type will cause the (wrong) code you wrote to (correctly) fail type checking. That is not the semver / LTS build I am asking for. I want semver / LTS for tool authors.

TS is now a central part of a massive ecosystem, and the TS toolchain is used by packages that never touch anything but vanilla JS. What I'm asking for is API stability for those toolchains. I found this issue because the LTS release of SonarQube (a static analysis tool) builds its TS/JS scanner on TS 4.0 even though they just released a patch for it 2 months ago. This means that if I want to scan our codebase, my code has to compile under that TS release. As far as I can tell, the problem is that significant engineering work is required to port their scanner to new TS APIs, which means that older (LTS) releases don't get back-ports and wind up stuck at the same version they started with, well over a year ago in this case.

I would like to see a range of API-compatible drop-in replacement TS builds. Adding a new (consumer-facing) compiler flag wouldn't be such a big deal if the (tool-facing) API didn't have to break at the same time.

[calidion]

It is a great contribution to the software development that the typescript team resists the stupidity that the SEMVER and the npm range introduced which greatly broking package stability in node ecosystem and making node useless for backend in some way.

And semver also cultivated a lot of zealots which force many companies adopting semver recklessly.
Still now those ignorant zealots are still force people to adopt that false rules.

Software can be kept stable only by full testing, the idea of keeping stability by auto update packages is totally wrong and violating basic principles of development practices.

[thw0rted]

Dude, you really don't have to reply to every single post in both issues. I said "semver / LTS" because I don't care if it actually follows the semver "spec", I just want them to publish a set of stable releases that have a stated goal of not breaking tools that consume their API, and I wanted to point out that this is a different goal from not breaking the build for users of tsc. I didn't mean to rile up the Anti-Semver League.

[black-snow]

WhyTF the hate for semver? Any update with whatever versioning schema you follow can mess up your app. You always have to test your stuff. It's not SemVer's fault if you don't.

At least SemVer gives you some semantics for what you can expect. You can set up renovate to bump and automerge patch and minor if your tests are green. If they are red you may have done something you shouldn't. On the other hand it shouldn't surprise you to see a PR for a major bump failing.

[calidion]

Semver has already ruined node.js' ecosystem which was once promising now has faded.

[calidion]

the companion locking files just signs indicate that sevmer is useless and wrong.

[calidion]

Version range, auto version update, semver are the three stupid things brought by the node.js eco which cause instability in node_modules and hence ruined the node.js ecosystem.

[calidion]

package-lock is a way to rescue but it is too late.