You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.json with target: ES5 when running tsc --init even though the actual default target is ES3. We should at least be consistent here.
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. 🌷
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 --target es5. on the other hand, the change includes a breaking change for existing customers who do not have --target specified.
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 --target ES5 to use a setter/getter is straight forward.
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.
Go with what you already settled with for the rest of the 2.x series, your reasoning totally makes sense.
Consider this for inclusion in 3.0, where there is room for breaking changes and this can also be clearly communicated ("new baseline: ES5"). Of course, depending on when 3.0 will happen, the new baseline can be set to either ES5 or ES6.
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...)
Activity
unional commentedon Aug 3, 2016
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. 🌷
RyanCavanaugh commentedon Aug 3, 2016
We'd still allow ES3 as a target, just not have it be the default.
unional commentedon Aug 3, 2016
Oh. I thought we are dropping ES3. XD
All for it then. :)
RyanCavanaugh commentedon Aug 22, 2016
👍 for TS 2.1. THE FUTURE IS NOW (eventually)
jcrben commentedon Apr 8, 2017
Looks like the milestone should be changed here, although target ES5 got set as the default for
tsc ---init. fyi, applicable code is at https://github.com/Microsoft/TypeScript/blob/2b61d18996c182b7de8ef2a9367210a70e3d4031/src/compiler/core.ts#L1458-L1474defaults 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
Changed default from ES3 to ES5
Changed default from ES3 to ES5
Changed default from ES3 to ES5
perlun commentedon Apr 29, 2017
Ryan Cavanaugh (@RyanCavanaugh) - see #15466.
Changed default from ES3 to ES5
Fixes microsoft#10117
mhegazy commentedon Jun 2, 2017
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
--target es5. on the other hand, the change includes a breaking change for existing customers who do not have--targetspecified.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
--target ES5to use a setter/getter is straight forward.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.
perlun commentedon Jun 2, 2017
Thanks for the details Mohamed Hegazy (@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...)