Add ES2016 target

[jods4]

For various reasons that are discussed in other issues, some people like to pipe TS into Babel for the downlevel (e.g. ES5) code generation. I won't reiterate here why one might want to do so.

Now that TS is starting to get ES7+ features such as async, decorators, possibly :: & co. it would be very welcome to add a ES7 (ES2016) target.

The use case today is to get raw, non transformed code from TS and process it with Babel.
The future use case is of course that JS runtimes are going to have some of those features natively supported and down-level emit won't be required anymore.

[kitsonk]

I still think this is challenging and that a simple "es6/es2015" or "es7/es2016" target won't solve the challenges... It almost needs some sort of granular feature flag. I am not familiar with it, but how is Babel handling these sort of control of these emits?

Also, is it a fair assumption at this point that an ES6+ feature ever be down emitted in ES6 as well as ES5/ES6? For something like exponation, the emit wouldn't change, but in theory if there was a down-emit for async to ES6, you could emit Promises but you couldn't do that to ES5.

[jods4]

@kitsonk OK, I'm going on a tangent with respect to this ticket.

The business of emiting JS for down-level browsers is a complex thing, which is mostly unrelated to the TypeScript language. On several aspects, Babel does a better job than TS at this. That's why some people pipe TS (for static typing) into Babel (for ES5 emit).

Granularity is one example of this. Babel supports enabling/disabling any Transformer individually. That's why it is enough that TS passes through ES7 code, I can handle the granular transpiling with Babel.

I don't mind TS supporting more emitting options (I think granularity is #4692), but letting the ES7 code passthrough is an easy step that supports such a workflow right now.

Also, is it a fair assumption at this point that an ES6+ feature ever be down emitted in ES6 as well as ES5/ES6? For something like exponation, the emit wouldn't change, but in theory if there was a down-emit for async to ES6, you could emit Promises but you couldn't do that to ES5.

Not sure I got the point here.

[robotlovesyou]

A real world use case for this would be the next major release of Koa.js which will natively support async/await in addition to the current generator syntax. While it works nicely with async functions transpiled by Babel it does not play well with the async functions transpiled by typescript (although I guess maybe that could be addressed separately).
It also seems cleaner to me to have typescript deal with all the static analysis stuff but have a specialised tool like Babel handle the transpiling from ESn to ESm

[kitsonk]

Not sure I got the point here.

There are likely to be features introduce in ES7 and beyond that would be better to emit as ES6 when possible. For example you could use WeakMaps/Promises/Symbols to better polyfill functionality in ES6 which is likely more performant (and less likely to have unintended consequences). Even using let and const in the down emit can make code behave better (and be less likely to leak/interfere with other code). Let's say decorators... maybe the environment doesn't support decorators (ES7) but supports classes (ES6). Why down emit everything to ES5?

Again, I don't see anyway of properly supporting it without some sort of micro-targeting. ES7/ES2016 will be a moving target for a long time.

[robotlovesyou]

@kitsonk I may be misunderstanding you but I think Babel allows you to do exactly that. It gives you fairly granular control over what transforms and polyfills you use to emit code, so for example when targeting node >= 0.12 I can turn off the regenerator transform to take advantage of native generator support.
If there were a way to leave all es7 features untouched in the output, in exactly the same way as the es6 target leaves all es6 features untouched, then a downstream transpiler such as babel could be used to selectively transform code or not as the platform requires.

[jods4]

@kitsonk exactly what @robotlovesyou said.
In babel each feature is handle by a specific transformer, and each one can be enabled/disabled as you want. So to quote your example, I could have "native" ES6 classes and transpile the decorators.

Anyway, in the long run as browsers evolve we will not transpile code anymore so a ES2016 target is required, juste like an ES6 target was added back then.

Another added benefit is that it enables TS team to add new features without downlevel support first (or ever... let in loop captures?). They did that for several features in the recent releases and I love it because it means sooner availability of async, etc. And we can still downlevel emit with Babel...

[mhegazy]

While it works nicely with async functions transpiled by Babel it does not play well with the async functions transpiled by typescript

@robotlovesyou can you elaborate on the issue here? can we file another issue with more details? if it is not working we would love to know why and what can be done to fix it.

[mhegazy]

We have discussed adding a --target ESNext or something along these lines. the problem is ES7/ES2016 is not finalized yet. proposals that reach stage 3 are likely to be in, but it is not clear about the other ones. for instance it is not clear that decorators will be in ES2016.

[jods4]

@mhegazy I think TS is evolving along with ES specs.

You support ES2016 proposals so I think it makes sense to have a ES2016 target.

If a feature slips out of ES2016 -- e.g. Decorators -- I suggest you update the TS compiler to polyfill them in ES2016 and let them through in the ES2017 target.

Indeed for people that want to always be on the bleeding edge, an ESNext target that transpiles nothing at all is interesting. Especially for scenarios like Babel.

[kitsonk]

I may be misunderstanding you but I think Babel allows you to do exactly that.

I thought we were talking about TypeScript. The proposal was to add a new target to TypeScript. I am suggesting that @jods4 proposal over simplifies that problem and that something more is needed and that has additional considerations.

If a feature slips out of ES2016 -- e.g. Decorators -- I suggest you update the TS compiler to polyfill them in ES2016 and let them through in the ES2017 target.

The challenge with that is one day you compile and you get passed through code, and the next day you get down emitted. 😦

[jods4]

I am suggesting that @jods4 proposal over simplifies that problem

I think the point is that there are different "problems" at hand, and this issue is not meant to solve your "problem".

My problem is that I want to be able to get JS code without any transpiling at all.
Your problem seems to be that you want more granularity for individual transpiling features.
They are not the same.

Today TS works with standards-based targets: ES3, ES5, ES6. Now that we start adding ES7 features we should add a matching target. It is the natural continuity of existing TS and makes perfect sense.

I don't mind introducing more flexibility, but that's a different discussion.

The challenge with that is one day you compile and you get passed through code, and the next day you get down emitted.

Is it a challenge? If you say "I want to target ES7 compliant browsers" and decorators are not in the standard anymore, then it's as it should be. Given that ES7 is not finalized yet if you ask for such a target you should be ready for that. And "down emitted" code would actually still works.

If you want stability target something stable, like ES5 or ES6.

If you want the bleeding edge, I think we need a new ESnext target or something like that, although that was not the initial point of this issue.

[kitsonk]

If you say "I want to target ES7 compliant browsers"

I think that is the root of the problem... We are likely to be in a constant evolving situation, where browsers will likely ever be in a static situation where you can specifically target that browser. Kangax's compatibility tables demonstrate this clearly. The agreed standards are already a moving target and then the standards that aren't even close to being finalised. There will never be something as an "ES7 compliant browser". Likely TC39 will cut ES7 as whatever is agreed at a particular point in time and everything else gets rolled forward. Like Object.observe was part of ES6, then moved to ES7 and may or may not make that, though V8 already has it implemented.

[jods4]

There will never be something as an "ES7 compliant browser".

Actually, most likely there will.

It is my understanding that Edge was planned to be ES6-compliant this year and that FF and Chrome are working hard to follow suite as soon as possible.

That's great news and it means we won't need polyfills for all this stuff in 2016 (if you can target the latest browsers only, of course). Something similar will happen for ES7,you just need to wait a little longer.

Given the new TC39 yearly schedule, ES7 is ES2016 and it will be frozen next year. Give it one (or two?) years and you'll see ES2016 compliant browsers.

And then we'll need a ES2017 target next year.