Repository navigation
(horrible idea?) support some kind of workflow using both TypeScript (specifically, compile-time type checking) and traceur #232
Description
Currently if I want to use ES6 features and async/await I have to use traceur instead of TypeScript. Now, those are on the roadmap for TypeScript 2.0, but for argument's sake, I think it's reasonable to say that traceur (or something similar) will be 'ahead of' TypeScript WRT ECMAScript features, simply because that project intentionally adds support for things even before they're "locked down" in the spec, while TypeScript (AFAICT from some of the github issues) chooses to wait until the spec is finalized (a perfectly reasonable engineering decision).
Since traceur supports type declarations, one possible workflow would be for TypeScript to be used in a workflow to do the type checking. In this scenario, TypeScript wouldn't need "full" support for new features it doesn't support (let, const, template literals, etc), but instead could be used in a 'sanity checking' way - it wouldn't need to "transpile" down to ES5, just provide type checking. There could either be no output created, or the output could be the same as the input, or the output would be the input with type declarations removed.
It seems like in the future, there could even be a fork of TypeScript that didn't have any transpile support, but simply provided type checking (leveraging that traceur supports the type declarations), and left transpiling to traceur (or similar). I don't know enough about the existing TypeScript compiler to know if this would actually be a significant savings or not, since the parsing and type checking might have enough complexity required such that the transpiling part ends up being a relatively small part of the overall code. If that's the case, then such a fork would likely not have significant savings over the current approach and wouldn't be worth the effort.
In any case, if there's some possible way to get the TypeScript-like type-checking tooling on "javascript.next" without having to wait for TypeScript to implement support (for ES6 + async/await currently, but more generally "future ES features"), that would be awesome. :)
Activity
RyanCavanaugh commentedon Jul 28, 2014
The great majority of the complexity in the ES6 features is the type system impact; emit is usually quick to figure out. We're basically already adding ES6 functionality as fast as we can design it; supporting not-finalized future ECMAScript proposals is out-of-scope for TypeScript.
jamesmanning commentedon Jul 28, 2014
Gotcha, thanks - I ❤️ TypeScript, and have been trying to figure out how to get async/await (supported by traceur --experimental), which makes my nodejs code so much nicer (just like C# 5 did for Task :) without having to leave TypeScript at the moment. I'm really looking forward to it getting potentially added during 2.x 😄
For now I'll try a split where I author most things with TypeScript and use traceur with async/await for particularly async-heavy / orchestration classes.
If/when TypeScript starts adding async/await of some sort, even just in a dev branch, please let people know so we can start trying to use it 👍
Thanks, Ryan!
RyanCavanaugh commentedon Jul 28, 2014
Thanks for the follow-up. It might be feasible for someone to do a fork of the compiler that supported the ES6 keywords with pass-through emit and no typechecking, which might help your workflow.
axelhzf commentedon Aug 7, 2014
I think that this could be a good idea. For example in the case of generators, node v.0.11.x already support it. Typescript could pass-through the generator code and if ES5 support is needed, use traceur.
seanhess commentedon Sep 18, 2014
I can't seem to find an issue specifically for generators / yield support on an ES6 target. It's related to #232 and #595, among others.
I have time and interest in making this happen. Is anyone working on it yet? How can I help? Would it make sense for me to begin work on this?
Ryan Cavanaugh (@RyanCavanaugh)