ES6 Generator support

[wizzard0]

This can be broken down to 3 areas:

1. basic (parser) support, even if we lose typechecking locally
2. Typechecking support
3. Transpiling like facebook/regenerator or Traceur, for targeting ES3/ES5.

Any timelines on this?

[DanielRosenwasser]

We have basic parser support (#1268). As our roadmap specifies, 1.5 is the target for emit, though I'm not sure if that includes the ES3/ES5 polyfill.

Since I don't see an official issue tracking it, I think this might be a good candidate!

[JsonFreeman]

Please take a look at #2873 and let me know if this addresses your needs.

[buzinas]

I've just seen that the TypeScript 2.0 milestone was added to support transpiling generators to ES5: do you have any estimate when it will be released?

[omidkrad]

@buzinas I don't know when to expect it but until then the workaround is to get TypeScript code with async/await transpiled to ES6 and then in a second build step use Babel to transpile that to ES5.

[buzinas]

@omidkrad Yeah, I know that, did this for one project, but for the others, I'm trying to keep things dry, so, I'm using only TypeScript as transpiler.

For bigger projects, the build time of two transformations doesn't compensate for us. Also, the sourcemaps don't work well when transpiling two times, unfortunately (they work, but poorly sometimes).

At the moment, we're sticking with promises, and it's good enough for 90% of the cases.

[DanielRosenwasser]

I think we'll have a beta ready to use towards late May/early July, though no promises on dates.

[piotrwitek]

@omidkrad For me using Babel just for transpiling async/await to ES5 was a a little bit of overkill, so for that workaround in my projects I'm currently using https://github.com/facebook/regenerator, works fine, but I cannot wait to finally have it possible by only using TS

[omidkrad]

@piotrwitek Nice tip! Do you run generator on tsc's ES5 output?

[piotrwitek]

@omidkrad yes "target": "es5", then I'm running regenerator -r app.ts-es5.js > app.es5.js, I needed this mainly because of IE10+ support and it's working fine, just need to include ES6 shim for Promises

[vigie]

@piotrwitek I'm missing something - how do you get tsc to compile your code to es5 in the first place if you have async/await syntax in there?

[piotrwitek]

@vigie Actually it's really good question, when using compiler you got async compilation error (Async functions are only available when targeting ECMAScript 6 and higher.), but transpiled code using generator functions is still emitted just fine, in Atom I'm using target es6 for eslint and typescript compile but with noEmit flag so normally I don't see any of these errors during development, then down my workflow I'm using SystemJS/JSPM to build bundle with target es5, on bundle step I don't have to care anymore about compiler errors

[vigie]

@piotrwitek A very interesting technique, thanks for taking the time to explain it. I'm currently evaluating introducing Babel into the chain, but its great to know you have had success with this lighter weight option.

[zpdDG4gta8XKpMCd]

it's late may and still no promises, learn to type faster! 😜

[jonaskello]

Big +1 on this feature. With this feature, my team's development flow could be 100% integrated inside VS2015. Currently, because we need generator functions, we need to introduce double compiling with babel and loose a lot of VS2015 integration (compile on save, error reporting, and debugging). Really looking forward to using this feature once it is implemented.

[MattiasBuelens]

Is this still on track for TypeScript 2.0? The implementing PR #9175 for this depends on the new emitter #5595, but the milestone of the latter has been updated to 2.1.

I'd appreciate it if one of the core contributors could update the roadmap and the issues linked in the roadmap with the correct milestones. It'd help get a better idea what to expect in 2.0, because right now there's a lot of conflicting information.

[WanderWang]

2.0 or 2.1 ?

[jonaskello]

@kdalgaard I think the confusion here might be that when you use jspm then you do not use tsc at all. Instead something called plugin-typescript is used and it handles the compiling by calling into typescript API. So I guess plugin-typescript just ignores generator functions and outputs them. Then regenerator can run and fix them. If you look as here in @piotrwitek's starter you will see that it actually compiles to es5, but not with tsc, instead plugin-typescript is used as you can see here.

[kdalgaard]

@jonaskello Thanks for that.

I wonder how plugin-typescript is able to use the TypeScript compiler in a way that keeps generators intact.

At any rate, it seems like a pretty flaky strategy from plugin-typescript to just output ES6 syntax even if the target is set to ES5...

[piotrwitek]

@kdalgaard @jonaskello it is working because TypeScript compiler can emit files even when there are errors, so it will emit code compiled to es5 without transpiling generators, but the rest of transformation is good (NOTE: noEmitOnError flag should be false)

[kdalgaard]

@piotrwitek I understand as much. The million dollar question now is: How?

I'm looking for a more TypeScript generic method than the somewhat questionable programmatic use in plugin-typescript for JSPM, where errors are apparently ignored. If there's an option somewhere that enables this, then at least it's a flaky strategy that I've chosen myself.

[jonaskello]

@kdalgaard I have not tried it but I think the tsc option is --noEmitOnError = false, which is the default. I think even if tsc will yell at you and exit with error it will still emit what it can. I guess plugin-typescript does the same but without yelling at you or exiting with error.

[kdalgaard]

@jonaskello Can't seem to get it to work. Maybe something with my Webpack setup or trouble with TSLint...

How do you all become aware of actual script errors, if everything is output anyway?

[jonaskello]

@kdalgaard I can describe my workflow if it helps. In my previous project I used webpack. Everything was compiled, type-checked and bundled in-memory using webpacks dev-server, and then it hit the browser. So when it hit the browser I was sure it compiled and was type-checked. In the beginning this was really fast. Now that project has grown, initial webpack build takes 36263ms and incremental takes 16981ms. So for my current project I decided to try jspm instead. Not sure if it is any better, but at least it is different :-). So I found @piotrwitek's jspm starter and did not really understand how that worked because it is so different from the webpack flow. Then I finally understood. You have to realise that code is not compiled, not type-checked and not bundled before hitting the browser. It is simply just transpiled, bascially it just strips the type information without caring about it. This makes it possible to have JS hitting the browser fast which makes it possible to make changes in TS and iterate really fast. But I had the same question as you, how do I know if there is a compile error? Well, you have to have a second place where you do that. For example you can use atom with the plugin that incrementially compiles and type-checks. Or you can simply use any editor and just run tsc --watch in the termial, which is what I do. So what I finally realised was that compiling/type-checking could be a separate concern to getting the JS into the browser. Granted this is very different from how webpack works and you have unlearn a bit. And of course this is not the only workflow for TS in jspm, it is just the one I have currently adopted.

[kdalgaard]

@jonaskello Thanks for the explanation. I would expect Webpack to continue being fast due to hot module replacement, but I don't know...

[sheerun]

@DanielRosenwasser @jonaskello As demonstrated by fast-async you don't need generators to support async/await, promises are enough. Please don't despair and implement async/await for es5 in typescript.. The the only thing that is blocking me to switch.

[jonaskello]

@sheerun This issue it not about async/await. It is about generator functions. AFAIK async/await -> ES5 is already implemented in ts@next. Async/await is great if you are taking a imperative approach but IMO not useful if you are using a functional approach to side-effects such as redux-saga.

[kdalgaard]

@sheerun What @jonaskello said.

[jonaskello]

Now that #5595 has landed, is there any chance this issue can make it back onto the roadmap?

[normalser]

Looks like there is a chance: #12346