Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ES6 Generator support #1564

Closed
wizzard0 opened this issue Dec 26, 2014 · 70 comments

Comments

@wizzard0
Copy link

commented Dec 26, 2014

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

This comment has been minimized.

Copy link
Member

commented Dec 27, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Apr 27, 2015

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

@buzinas

This comment has been minimized.

Copy link

commented Apr 4, 2016

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?

@kitsonk kitsonk referenced this issue Apr 19, 2016

Closed

New TypeScript 2.0 Features #37

0 of 4 tasks complete
@omidkrad

This comment has been minimized.

Copy link

commented May 13, 2016

@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

This comment has been minimized.

Copy link

commented May 13, 2016

@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

This comment has been minimized.

Copy link
Member

commented May 13, 2016

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

@piotrwitek

This comment has been minimized.

Copy link

commented May 13, 2016

@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

This comment has been minimized.

Copy link

commented May 13, 2016

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

@piotrwitek

This comment has been minimized.

Copy link

commented May 15, 2016

@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

This comment has been minimized.

Copy link

commented May 18, 2016

@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

This comment has been minimized.

Copy link

commented May 18, 2016

@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

This comment has been minimized.

Copy link

commented May 19, 2016

@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

This comment has been minimized.

Copy link

commented May 25, 2016

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

@jonaskello

This comment has been minimized.

Copy link

commented Jun 22, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Jul 1, 2016

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

This comment has been minimized.

Copy link

commented Jul 10, 2016

2.0 or 2.1 ?

@jonaskello

This comment has been minimized.

Copy link

commented Oct 11, 2016

@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

This comment has been minimized.

Copy link

commented Oct 11, 2016

@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

This comment has been minimized.

Copy link

commented Oct 11, 2016

@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

This comment has been minimized.

Copy link

commented Oct 11, 2016

@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

This comment has been minimized.

Copy link

commented Oct 11, 2016

@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

This comment has been minimized.

Copy link

commented Oct 11, 2016

@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

This comment has been minimized.

Copy link

commented Oct 11, 2016

@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

This comment has been minimized.

Copy link

commented Oct 12, 2016

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

@sheerun

This comment has been minimized.

Copy link

commented Oct 19, 2016

@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

This comment has been minimized.

Copy link

commented Oct 19, 2016

@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

This comment has been minimized.

Copy link

commented Oct 19, 2016

@sheerun What @jonaskello said.

@jonaskello

This comment has been minimized.

Copy link

commented Nov 9, 2016

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

@normalser

This comment has been minimized.

Copy link

commented Nov 18, 2016

Looks like there is a chance: #12346

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
You can’t perform that action at this time.