(horrible idea?) support some kind of workflow using both TypeScript (specifically, compile-time type checking) and traceur

[jamesmanning]

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. :)

[RyanCavanaugh]

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]

The great majority of the complexity in the ES6 features is the type system impact; emit is usually quick to figure out

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 😄

• Traceur currently strips the type information during its transpile down to ES5 (which makes sense), so I can't effectively use Traceur-then-TypeScript as the type information is gone.
  • they have a task to keep the type information in a jsdoc format (using @param and the like) since many teams (like Angular) compile the result with the Google Closure Compiler which can include type checking
  • when/if that gets done, I might be able to add a post-process step or change that code to add the type declarations back so the resulting "ES5-with-type-declarations" can then be compiled by TypeScript and include type checking
• TypeScript doesn't accept/ignore the ES6 or async/await keywords (which makes sense), so I can't do TypeScript-then-Traceur since the compilation will fail with syntax errors

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]

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]

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]

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?

@RyanCavanaugh