Are you going to break it again?

[deadmann]

I just wanted to know if you are going to break compatibility in typescript again????

i wrote a whole library in in webstorm using 2.x version, which i had issue in vs till i found some version, or blocked ts compiler wholly, then i got to angular and vscode, and had to put a whole day modifying it to work. then i checked it in and came home... same project, same ts configuration, same code, under same compiler name "tslint", ts didn't worked, 2K error :| completely broken, everything was off, took me more than a whole work day to fix all issue, and still some remains...
worse than that... I'm not sure if the next time i open my project in the company PC, my code are broken again or not :|

If you are going to break like some cheap unmanaged open source software, tell me to stop trying to write usable code for this language anymore, and stop using and relying, and even trying framework based on it for my next projects :|

even code in stack has low chance that match someone issue since there are so many vast different way of compiling typescript

[dragomirtitian]

This is wholly unactionable.

There is a breaking changes section. Some are bigger, some are smaller but generally they are not on common scenarios.

If you had specific issues that are not documented there, add them and we can see what went wrong, otherwise this ticket does not really seem productive.

I think the TS team generally tries to minimize breaking changes from version to version and don't do so unless there is a good reason.

[RyanCavanaugh]

😐

We'll sometimes need to make changes that can end up creating new type errors in existing programs - this is ultimately unavoidable, because for any change in the type system, including bug fixes, it's possible to construct a program that will have a type error introduced into it as a result.

tslint is a separate project and we have no control over it.

[deadmann]

well the first time i learned TS it was like classes and /// <references...
then it became module, then reference changed to import, then interface got broken, ..... and even in middle of all these, it got treated differently in other placed an compilers...

[nattthebear]

<reference> is still supported, and works for ambient declarations. You have to import modules to use them, but that's not a breaking change because modules were a new feature. The behavior of interface has not changed in forever, so I don't know what you're referring to with that.

[poseidonCore]

I feel for @deadmann. Every time I see the issues counter go up ... and instead of issues being consistently solved before major releases are made, new features are added ... and performance suffers.

There are so many significant breaking changes between minor versions now, I really wish that new features were held over to major releases so that the actual language structure can be set for each major release.

A good example of this is the push for contravariance vs covariance. This may seem like just one change, but in large projects, this one change can break things all across the application.

Programmers don't seem to have the same EoL support as with other languages: with TS, if you don't constantly upgrade to take on new language constructs, you don't get fixes to old issues.

Using a living standard model is becoming laborious in this way. If Node.js can manage a LTS version and a progressive version, surely TS can take the same approach.

However, I do appreciate all the effort that Microsoft has put into this language. I could not program efficiently without TypeScript now.

[deadmann]

I just wished my code could work everywhere with at least minimal changes,... and training people in a same way, every library is wrote completely in different manner, and even if one doesn't break another does.

[basarat]

every library is wrote completely in different manner, and even if one doesn't break another does.

That's just JavaScript in my opinion. Not something that the TypeScript team controls 🌹

[kitsonk]

I really hope they keep breaking it. Being the lead on a library for several years, most of the forced refactors were pretty straight forward and in almost every case made our code either more sound or easier to be consumed. Now I work on a runtime that embeds TypeScript and 3.5.1 has broken some code, thought it took me all of about 15 minutes to make the changes to adopt it, and in every case, it broke because we were being a bit loose with the types. While it didn't find any bugs, it made the code more "safe".

If you dig into the details, you will see that the TypeScript team take breaking changes very seriously and with consideration. I remember a couple that had a wider impact than they anticipated a few years ago, but now they tend to do a lot of analysis against some codebases and DT. If you look, you will see a long long discussion of things that broke in VSCode with 3.5, and I think all those break ended up being "good" breaks including some that were unsafe APIs that probably should have exploded at runtime.

So again, I really do hope the team keep breaking my code to make it better.

There are so many significant breaking changes between minor versions now, I really wish that new features were held over to major releases so that the actual language structure can be set for each major release.

The TypeScript team has made it clear. They do not follow semver. "minor" (X.X) releases can contain breaking changes. Major releases (X) have very little meaning.

[poseidonCore]

I really hope they keep breaking it. Being the lead on a library for several years, most of the forced refactors were pretty straight forward and in almost every case made our code either more sound or easier to be consumed.

The fact that this process works for you, does not imply that it works for others. Providing a LTS version would help for those that want to keep with one stable version. Your pathway robs others of that option.

The TypeScript team has made it clear. They do not follow semver. "minor" (X.X) releases can contain breaking changes. .

The fact that someone has made a bad policy clear, does not mean that the policy is therefore good.

Major releases (X) have very little meaning.

This negates the usefulness of using such versioning in the first place.

[kitsonk]

The fact that someone has made a bad policy clear

Why is it a bad policy? It is a policy. It is one that doesn't meet your expectations. Doesn't make it bad.

[poseidonCore]

It's bad for the obvious effects that are being expressed here.

Your comment on "expectations" is misplaced ... by the same token, I could say "Simply because it meets your expectation, that does not make it good".

My point is that different programmers do have different expectations and they decide for themselves what is good for them, ... but I am not robbing you of the access to latest features by saying that we should have a LTS version and a progressive version, ... whereas your pathway of just having a progressive version removes that stability for those programmers like @deadmann who do want that stability.

Most programming languages have at least 2 supported versions for this very reason. My argument is simply that TypeScript has evolved to the point now where it should consider that option as a means of avoiding the frustrations that programmers like @deadmann have, while still catering for programmers like you.

[deadmann]

well to be honest i don't want to put it all on TS, as changes on JS standards is what also push ts compiler to some of (not all) those extends... js treat variables differently if there's strict or not, but more than that, it tread differently if it's es5 or es6, and maybe others... you may find code that perform differently
from es5
to es5 strict
to es6
to es6 strict
...

It's even hard to know who to hate :|