-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Transpiling ES6 generators into a ES5 state machine? #3975
Comments
You can compile with
Just work that needs to be done. It will come with release 1.6 :#1664 |
Will I lose the ability to debug the original .ts files via source maps? Theoretically a tool like traceur could take into account a preexisting source map and generate a composition of source maps, but I have a doubt that traceur is this advanced.
Thanks. This answers my question. |
To be clear, targeting ES6 with async will be supported in 1.6. Not downlevel support. My understanding is that the work required is understood (#1781), but the team is still weighing the complexity/gain tradeoff. |
As mentioned, this is on the table, we just haven't done/committed to it yet. |
Will this be implemented? why is this issue closed? |
Please note, this is gated on #5595 |
Any progress on this? #5595 has been resolved. |
Downlevel generator support has been declined due to excessive complexity and inability to achieve 100% feature parity. Notes at #10307 |
For anyone looking for a solution, here is how I solved it. I set target: "es6" in tsconfig compilerOptions. This is all I do for dev, it works fine for me in chrome 52, but I needed to set module: "commonjs" as well because chrome complained about import statements. Then for production I just pass the output through babel. For example I'm using webpack so my webpack.config.js looks like this: const typescript_loader = process.env.NODE_ENV === 'production' ?
'babel-loader?presets[]=es2015!ts-loader' :
'ts-loader';
// lines omitted
module: {
loaders: [
// other loaders
{ test: /\.tsx?$/, loader: typescript_loader },
],
preloaders: { ... },
}
// rest omitted |
This was sad news for the part of react/redux community that have adopted redux-saga for side-effect where generator functions are essential. @nhjk I think regenerator is a more lightweight work-around. |
Very sad, indeed... @jonaskello Do you have an example of how you use regenerator with Webpack to support redux-saga? |
@kdalgaard Sorry, I have no examples for webpack close. However I know this starter is using regenerator with jspm. Maybe you can have a look and do the same for webpack. |
If async await landed in TS 2.1, and these are using generators, how come that generators are not possible to include? Thanks! |
Generator support should be available in the next release. see #1564. |
This must have been discussed here, but I couldn't find that discussion. So what's the reason for not supporting es6 generators when targeting es5?
In my spare time I'm writing a tsumego (it's like a mating problem in chess) solver in js which is supposed to be run on a tsumego hosting site like goproblems. This means that the solver must be es5-compatible. The solver itself is a fairly complicated variation of the depth-first search which is, obviously, recursive and can easily go 30-40 stack frames deep. Debugging such a recursive algorithm is a nightmare. I obviously needed a way to implement a special tsumego debugger that would let me use F10, F11, Shift+F11 to suspend and resume the solver at some interesting locations in the search tree, but a conventional recursive function doesn't allow to do that: it either runs to the end or just hangs due to some bug causing a tricky infinite loop 30-or-so levels deep in the search tree. So I had to rewrite the solver in a non recusrive form, which made it much less elegant. Today I've realized that what I actually needed is a recursive generator that would yield at every node in the search tree and yield* itself when it needs to go deeper.
I'm aware of transpilers like traceur that can do this transformation, but I'm afraid that this won't work with tsc well: if I write yiled* in a ts file, vs2015 will complain about the syntax, tsc will simply fail and traceur won't be able to do much due to ts-specific type annotations.
The text was updated successfully, but these errors were encountered: