Consider changing default target to ES5
#10117
Comments
RyanCavanaugh
added
Suggestion
|
One small counter argument. When I first get my hand on TypeScript, it is the ability to transpile down to ES3 that gets me to choose TypeScript over ES6 with Babel. Of course things changed since then and more and more features are added. So my personal opinion on this is mixed and neutral. 🌷 |
|
We'd still allow ES3 as a target, just not have it be the default. |
|
Oh. I thought we are dropping ES3. XD All for it then. :) |
RyanCavanaugh
added
Help Wanted
|
👍 for TS 2.1. THE FUTURE IS NOW (eventually) |
|
Looks like the milestone should be changed here, although target ES5 got set as the default for defaults are apparently in various places; e.g., charset is at https://github.com/Microsoft/TypeScript/blob/0fd0903280d9c5090f18bcc22b7df7ca608857b1/src/compiler/sys.ts#L196-L223 seems worthwhile to move towards handling them in one place |
Fixes microsoft#10117 The fix was easy, but then I had to get the tests passing: ```shell $ gulp runtests # loads of failures, more than 1000 actually. $ gulp baseline-accept $ gulp runtests # to make sure they now passed ``` ...and then `git add .` to add all the changes. (There were a bunch of new files created when I did it like this; is that correct?) -- (Regarding the unrelated changes in `compileOnSave.ts`: I happened to see a few typing mistakes there very close to the changes I were making to that files, so I bundled that change along at the same time. Since the tests are passing I think it should be fine.)
Fixes microsoft#10117 The fix was easy, but then I had to get the tests passing: ```shell $ gulp runtests # loads of failures, more than 1000 actually. $ gulp baseline-accept $ gulp runtests # to make sure they now passed ``` ...and then `git add .` to add all the changes. (There were a bunch of new files created when I did it like this; is that correct?) -- (Regarding the unrelated changes in `compileOnSave.ts`: I happened to see a few typing mistakes there very close to the changes I were making to that files, so I bundled that change along at the same time. Since the tests are passing I think it should be fine.)
Fixes microsoft#10117 The fix was easy, but then I had to get the tests passing: ```shell $ gulp runtests # loads of failures, more than 1000 actually. $ gulp baseline-accept $ gulp runtests # to make sure they now passed ``` ...and then `git add .` to add all the changes. (There were a bunch of new files created when I did it like this; is that correct?) ---- (Regarding the unrelated changes in `compileOnSave.ts`: I happened to see a few typing mistakes there very close to the changes I were making to that files, so I bundled that change along at the same time. Since the tests are passing I think it should be fine.)
|
@RyanCavanaugh - see #15466. |
Fixes microsoft#10117 The fix was easy, but then I had to get the tests passing: ```shell $ gulp runtests # loads of failures, more than 1000 actually. $ gulp baseline-accept $ gulp runtests # to make sure they now passed ``` ...and then `git add .` to add all the changes. (There were a bunch of new files created when I did it like this; is that correct?) ---- (Regarding the unrelated changes in `compileOnSave.ts`: I happened to see a few typing mistakes there very close to the changes I were making to that files, so I bundled that change along at the same time. Since the tests are passing I think it should be fine.)
(Regarding the unrelated changes in `compileOnSave.ts`: I happened to see a few typing mistakes there very close to the changes I were making to that files, so I bundled that change along at the same time. Since the tests are passing I think it should be fine.)
|
Had a discussion about this again in the design meeting today. There seems to be little benefit from the change since it basically saves you from writing It gets even more interesting that the breaking change is not easily detectable, i.e. the emit changes silently with no warnings, and users will have to figure this out the hard way. where as the current behavior of asking users to set The other ideological issues here is there does not seem to be a principal to choosing the default, ES3 is the minimum supported. ES5 is some value in the middle (though granted is the most common), but that means that we will do another breaking change in a few years to pump it to ES6 when that gets widely used enough, and it is not clear where does that stop. So to conclude, do not think we will do this after all. sorry for flip flopping on it. |
mhegazy
added
Declined
|
Thanks for the details @mhegazy. My suggestion:
I think it's fine to go with first ES5 and then ES6, as long as it's clearly communicated, but of course it means a bit more work for you guys. Semantic Versioning is the agreed-upon contract within the industry for handling these kind of things. In line with SemVer, I think your conclusion for 2.x is entirely right: we must not take this change in, since it's very likely that it will cause hard-to-find bugs and make people rightfully upset. They should be able to trust that 2.x will not introduce changes like this. So, I don't have any problem with this decision, as long as we are clear that it's temporal. (while "temporal" can mean anything from months to years...) |
ES3 runtimes are increasingly few and far between, and many common features (getters and setters, spread in
new) only work in ES5. The 2.0 release would be a good time to take a BC break to update the default target to ES5.Related, and somewhat confusingly, we emit a
tsconfig.jsonwithtarget: ES5when runningtsc --initeven though the actual default target is ES3. We should at least be consistent here.The text was updated successfully, but these errors were encountered: