Typescript: ES6 Generator support

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!

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

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?

@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.

@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.

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

@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

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

@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

@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?

@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

@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.

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

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.

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.

2.0 or 2.1 ?

Do not release TS 2.0 without async / await for ES5/3, the main feature. Otherwise it will be ridiculous.

@vbcodec I want it just as much as you do, but there is lots of new stuff in 2.0, so it wouldn't be "ridiculous" – maybe just disappointing.

It'd just be nice to have some indication from 'those in the know' what is happening with regards to this feature. With respect to varying levels of 'disappointing', personally losing this feature would ruin my ideals of what 2.0 is.

For the meantime, curiosity from not knowing is killing me more than the prospect of not having this feature :smiling_imp:

I would be very sad if this doesn't make it into 2.0, but it wouldn't be the end of the world -- I can just keep the Babel step a few more months, e.g. until 2.1 arrives with it. I'll just be glad to have 2.0 finally shipped, cause it brings so much other goodness for which there are no any workarounds that our community (Aurelia Framework) is waiting for.
A 2nd step Babel transpilation can still be used to get _async/await_ with a es5 target.

@glen-84
The fact is that implementing async/await is alerady ridiculous. It is few years when they 'plan to implement it in next version'. Maybe they do not want to implement it at all, and just playing bad game with us ? Only IE 11- need this feature, because Chrome and FF have support to ES6, and cost of implementing is very high. Why to make serious investment for leagcy standard on legacy browser on legacy Windows (8.1-) ? Just use Babel of lambdas if you want support legacy tech. This may be line of thinking by TS team.

The 'new stuff' is null-check, but this is much less usefull than anybody wish. Preventing null exceptions lead to complex declarations on code and data structures. JS/TS code is very dynamic, most libraries aren't designed with non-null philosophy, and will cause leaks and serious resistance while bending to non-null behaviour. That's why most devs will stay with 'more risky but much simpler code'.

@vbcodec there is much more 'new stuff' coming with 2.0 than just the _null-check_. For me, type declarations on this of any function is much more important, just as granular lib selection or the new typing resolution strategies are.

In any case, I would suggest not to flame this topic with irrelevant comments further, let's all patiently wait for an official response.

As noted in today's release announcement, we are happy with the implementation we have today for async-await (see https://github.com/Microsoft/TypeScript/pull/9175). The PR is in final code review iterations; and we hope it will be merged in master within few weeks. once that is done, it should be available for the general public in the nightly releases (typescript@next).

@mhegazy any news? is the merge imminent? Really looking forward to this feature release! :+1: :smile:

Yes, we desperately need async/await for ES5 ...

@HoosierMike desperate might be too much, but it does indeed feel like it! It overjoys me already to use async/await in ES6 node, can't wait to use it for ES5 frontend apps.

I see it's on the roadmap for version 2.1 , but how to know if it is in nightly build yet ? I'm assuming that is when we can easily grab at the bits. Thanks

Any ETA perhaps?

@devzsolt https://github.com/Microsoft/TypeScript/pull/9175#issuecomment-244181037

great news, thanks @glen-84!

Down-level generator support for async functions (async/await) is now in master and should be available via typescript@next tomorrow.

@rbuckton Will this support also cover compiling ES6 generator functions (function*/yield) to ES5? I'm guessing it does but from the description it seems to be only about async/await.

@jonaskello I saw that there was some work on partially down-leveling generator functions (not just async/await) in #10106, but that was apparently closed because the restrictions on what is and is not supported weren't clear (see #10307).

I think the idea is to implement just enough to transpile async/await, but not yet transpile _all_ generator functions. That way, the TypeScript team can ship this feature sooner because it only needs partial support for generators. I believe full generator support is still somewhere on the roadmap, but simply for a later version. (Don't quote me on that though, I'm not part of the TypeScript team. I just follow their progress in some interesting PRs. :stuck_out_tongue: )

If that is true then what has been merged into master does not solve this issue (which is titled ES6 Generator support). I had really hoped for generator function support. Maybe I am in the minority here but I have no use for async/await. I do all my side-effects in redux-saga which only uses generator functions. I guess one could argue that support for features that are part of ES2015 (generator functions) should be have priority over features that will be out in ES2017 (async/await). But still nice to see that progress is made in areas related to generator functions!

Nit: async/await won't "maybe" be out, they are stage-4, which means they
_are_ standard. The annual spec publishing is a formality.

On Thu, Sep 8, 2016 at 07:30 Jonas Kello [email protected] wrote:

If that is true then what has been merged into master does not solve this
issue (which is titled ES6 Generator support). I had really hoped for
generator function support. Maybe I am in the minority here but I have no
use for async/await. I do all my side-effects in redux-saga which only uses
generator functions. One could argue that support for features that are
part of ES6 (generator functions) should be have priority over features
that will (maybe) be out in a later ES version (async/await). But still
nice to see that progress is made in areas related to generator functions!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/1564#issuecomment-245439745,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEdfc7JxKejEJQ9azL0vwqBIAlI9SCzks5qnzrngaJpZM4DMZR_
.

@Kovensky Sorry about that, I don't follow async/await that closely. Last I checked it was stage-3 but things move quickly :-). Updated my comment accordingly. And don't get me wrong, I used async/await in C# since it was a technical preview and it is a really nice feature.

It would be great to use redux-saga with typescript and es6 generators.

http://yelouafi.github.io/redux-saga/

@jotaoncode You could already do that if you want use webpack+babel+typescript for your build process, like so:

_webpack.config.js_

module: {
    loaders: [
        {
            test: /\.tsx?$/,
            loader: 'babel-loader!awesome-typescript-loader',
            // ...
        },
    ]
},

_.babelrc_

{
    "presets": ["es2015", "stage-0"],
    "plugins": ["transform-regenerator"]
}

This way you can use ES2015 Generators & Async/Await syntax in combination with redux-saga, and down-level compile the code to ES5 (which would then also run in IE11)

@jotaoncode Seems like it is not going to happen, see #3975.

@drywolf you are right, I saw your repo related to typescript webpack generator sample, also seems like they already fixed the problem related to awesome-typescript-loader, so probably the temporary fix you did is no longer needed.
Many thanks for the help :)

I've been waiting for support for down-level generators in version 1.5, then 1.6, then 2.0, then 2.1.... Now I'm waiting again to hear from the team when they expect it to come. So dissatisfying...

My use case is redux-saga for side-effects and long-lived transactions.

I believe this is on the roadmap, is already merged, and is slated for November 2016 under 2.1. You can probably use these things today by using typescript@next?

https://github.com/Microsoft/TypeScript/wiki/Roadmap

https://github.com/Microsoft/TypeScript/pull/9175

My apologies if I'm missing the point here entirely. It's my understanding that async functions and generators are the same under the hood, but it may only be a subset of generator features that are implemented.

@jocull downlevel generator support has been removed from the roadmap altogether and looks unlikely to be implemented at all - see https://github.com/Microsoft/TypeScript/issues/3975#issuecomment-250859415.

Given that, I'm not sure why this issue is still open or what it is still tracking.

@kdalgaard

I've been waiting for support for down-level generators in version 1.5, then 1.6, then 2.0, then 2.1.... Now I'm waiting again to hear from the team when they expect it to come. So dissatisfying...

Same. Been waiting for this for a long time. And now it's silently not happening? Lame.

I guess for the most part you can develop using generator functions with ES6 output and use Chrome which has native support for generator functions. We have an interesting corner case though. We have a legacy Silverlight application that we are converting to react with redux-saga. So we need to run both SIlverlight and redux-saga on the same page. Silverlight does not run in Chrome, Edge so we cannot use them. Internet Explorer runs Silverlight but does not support generator functions, and since TS does not downcompile to ES5 we cannot use IE. Fortunately for us Firefox supports both SIlverlight and generator functions, however it does not support debugging from Visual Studio.

@jonaskello Would regenerator work? Or does TS do something to the generators when emitting ES5?

Hi @glen-84, Regenerator would work, you can read explanation and check working solution in my starter-kit project here: https://github.com/piotrwitek/react-redux-typescript-starter-kit#asyncawaitgenerators-transformation-when-targeting-es3es5-without-babel

@glen-84 Yupp it would work but then you need to include something like gulp or webpack or babel or something else that multiplies the complexity of the setup. It would be nice to just code Typescript in Visual Studio with full ES2015 support out of the box. Just code some TypeScript, set a breakpoint, hit F5 and off you go. Especially since we have a team that has been doing that for C#/Silverlight. Granted in the end you need bundling for production but it would be nice if not every developer has to learn about these tools.

I wonder if TypeScript could just use regenerator internally? I guess they might want to avoid dependencies though.

@rbuckton can you provide a summary of where we are with this?

@piotrwitek I have read that paragraph of your starter readme over and over, and I still can't see how you would perform the first step, which is compiling TypeScript down to ES5 with generators intact. I believe it will just throw an error when seeing this syntax?

In your starter repo, the compile target for TypeScript is ES6, which won't help at all – Babel will still be needed to transpile it the rest of the way down.

If there exists some way to make TypeScript ignore generators syntax when compiling to ES5, I haven't found it yet 👎

@kdalgaard thanks for pointing that out it means I'll have to add a new paragraph clarifying that which need you to know how plugin-typescript works.

To put it simply there is a seperate TS compiler config for production in jspm.config.js which target ES5. TS will normally emit valid ES5 code with generators passed through thats where regenerator kicks in to finish the job. Now you have valid ES5 with generator functions transpiled.

For development I use only ES6 because you will use evergreen browser anyway for dev so they have native generator support, no need to downlevel that during development and complicate things.
Then you will use build script to create ES5 code bundle using ES5 config explained above.

@piotrwitek I wish it were possible, what you describe, but on my machine, when trying to compile a TS script with generators to ES5, errors are emitted in the console, saying that this syntax is not supported for ES5 targets.

You can transpile ts to es6 while editing and configure jspm for babel es6
-> es5 transpilation

On 11 Oct 2016 9:23 PM, "kdalgaard" [email protected] wrote:

@piotrwitek https://github.com/piotrwitek I wish it were possible, what
you describe, but on my machine, trying to compile a TS script with
generators in it to ES5 results in errors in the console, saying that this
syntax is not supported for ES5 targets.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/1564#issuecomment-252872060,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADimvA7snR3nZ-Y6UBx6_pbq0xr7Z4nHks5qy2ORgaJpZM4DMZR_
.

@MaximBalaganskiy The point in question is how to avoid Babel.

Oh, I see. Then Piotr's approach should work. You configure tsconfig for
es6 and jspm for es5. Thus no errors in a dev console and right code in
browser.

On 11 Oct 2016 9:30 PM, "kdalgaard" [email protected] wrote:

@MaximBalaganskiy https://github.com/MaximBalaganskiy The point in
question is how to avoid Babel.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/1564#issuecomment-252873494,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADimvBZO2glcCnmKtnV8T_oOrXqg7qSeks5qy2VXgaJpZM4DMZR_
.

@MaximBalaganskiy I completely fail to see where in that description ES6 is compiled to ES5 without the use of Babel.

@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.

@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...

@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)

@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.

@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.

@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?

@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.

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

@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.

@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.

@sheerun What @jonaskello said.

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

Looks like there is a chance: https://github.com/Microsoft/TypeScript/pull/12346