Description
This is a radical suggestion but I think it makes sense.
Today, Typescript does two different things: it provides an awesome strongly-typed experience for coding javascript applications and it transpiles your code into equivalent javascript for various targets (es3, es5, es6).
These things are not strongly related and could easily be split into two distinct parts. In fact, lots of projects already try to do the second part. Notably 6to5, which is certainly the best es6 transpiler that exists today.
My suggestion is to drop any transpiling at all, drop the target options and always emit ES6 code. Because TS tries to align with ES, the emit code would mostly just remove the type annotations. This ES6 result can then be piped into 6to5 and we'll get our final js code, compatible with the browsers that we intend to support.
Why would you do that?
- Because emitting es5 code for es6 features is duplicating effort from other people. Your time is better spent in implementing the typing aspects of es6 --> faster progress for TS.
- Effort to emit es5 or even es3 code is wasted, in 5 years most people won't use it anyway.
- In (horrible idea?) support some kind of workflow using both TypeScript (specifically, compile-time type checking) and traceur #232 @RyanCavanaugh says that "emit is usually quick to figure out". I'm pretty sure this is not true: generators or async, which you have not done yet, are quite complicated. Looking at Class Inheritance is Not ES6 Spec Compliant #1601, Some ES6 constructs force an implicit 'strict' context within them. #1135 or Emit of 'arguments' in arrow functions is incorrect per ES6 spec. #1609 shows how time-consuming supporting edge cases of your codegen can be.
- 6to5 is a better transpiler than TS. In particular, it allows me to choose precisely what I want to transpile and which polyfills I include. For example, if I'm targeting IE11 I can choose to emit es6
letand transpileclassor=>.