Question: Would it be good to use Babel for Transpiling ES.next features?

[donaldpipowitch]

Recently a lot of projects working on/with JavaScript language features unified or at least came together to create new standards. AtScript was "merged" into TypeScript, there is the https://github.com/estree/estree project from Babel, Acorn and Esprima folks... and so I wonder if it would be good - also in terms of separation of concerns -, if TypeScript would just use Babel internally for all transpiling tasks, so it essentially just puts all type-related logic on top of Babel. It seems there would be at least some interest from other devs in such task (https://twitter.com/wycats/status/573553751362928641).

TypeScript could be easily integrated on top of existing Babel projects and it would probably stabilize Babels and TypeScripts transpiling tasks (because of shared knowledge experience), which could result in getting new features faster.

[matthiasg]

I believe its unlikely given that ms is quite strong in the compiler field and they might not want to ie inherit/work-in another parser/compiler codebase. That said, i would very much appreciate that.

This question for me boils down to the typescript/Angular announcement. I am unsure whether that was a good move (might be, just unsure for now).

As i mentioned in #2261 typescript is not ES6 and is not clearly delineating which features are typescript specific and which are ES6 in their docs and specs since they just recently even started pushing for ES6 support. In general I believe the thinking in the team is typescript is Javascript with a whole lot of optional extra features you can use without being concerned too much with consensus towards ES6. Actually thats what held me back from looking into that to begin with. It looks like Javascript but its not really, you never actually know where specific non JS features where used, unless you looked at the entire codebase or compiled it all and diffed it.

Generally though, provided Typescript is moving into a standards based direction with opt-in extra features i would very much appreciate the strength of the team behind typescript. Whether it makes sense to work with babel and opt-in extend for legacy typescript support or experimental would need discussion.

[donaldpipowitch]

As i mentioned in #2261 typescript is not ES6

If TypeScript sees itself as non-standard JS with type checking it would probably be more useful, if TypeScript wouldn't use Babel for standard JS transpiling (as it is non-standard), but modularize the type checking so it can be used with standard JS transpilers. (To say it differently: Instead of using Babel inside TypeScript as requested by me it would make more sense if I could use TypeScripts type checking outside of TypeScript like on top of Babel. That way TypeScript could keep its non-standard transpiling mechanisms.)

[jods4]

I suggested pretty much the same in #1641 (at the time babel was still known as 6to5). The response from the TS team was clear: they are not going to use babel to transform ts/es6 code into es5.

(The motivation for my suggestion was about speeding up the ES6 implementation process.)

Of course, you are free to use TS with ES6 target and then pipe into Babel if you think Babel has better transforms.

As i mentioned in #2261 typescript is not ES6 [...] In general I believe the thinking in the team is typescript is Javascript with a whole lot of optional extra features.

I can't speak for the team but I'm curious where you got that impression. They have a clearly stated goal to align as much as possible with ES6/7 and several discussions on github suggestions/issues show that they are careful about adding "optional extra features".

BTW I'm not even sure what are those "whole lot of optional extra features". Of course there's the typing, but that's the whole point of TS. Then what? Modules were added before standardization but they are now aligning on ES6 spec. public/private modifiers inside classes are an addition, although it's more at the typing level than anything else, as it doesn't translate private to use Symbols or anything. Out of curiosity, what lot am I missing?

[danquirk]

As noted, the pros and cons here were pretty well covered in #1641.

[balupton]

Sorry to re-open this here, but it seems like the best place.

Considering Babel v6 came out, which uses a modular plugin approach - pretty much all the arguments that were previously used in the threads around this have fallen away and are no longer applicable.

TypeScript's parsing and transpilation abilities would essentially just become babel plugins, with a typescript prefix.

Flow Type went the babel route with its own babel plugins, allowing you to write ESNext code in Babel, then use babel to compile that source code to whatever target you want by just changing presets and/or plugins.

Such adoption of Babel v6 would:

1. Allow typescript to just focus on its core value scope only - typing - leaving parsing and transpiling up to babel which is babel's core value scope only
2. Inherently solve all the transpile target requests and esnext feature requests and corresponding maintenance that are already present in this repo and will continue https://github.com/Microsoft/TypeScript/issues?utf8=✓&q=is%3Aissue+babel+

[ciekawy]

looks like there is some more interest in this approach:
https://www.quora.com/Is-it-possible-to-implement-TypeScript-as-set-of-babel-6-plugins

[tracker1]

I'm interested in the approach... @decorators are pretty well sketched out at this point, though implementations could use a little TLC, and argument decorators still need work. That said, I'd like to see flow and ts align and become babel plugins... Personally not a huge fan of .ts as babel has moved faster, but in working with Angular2 now, it's been more difficult without TypeScript.

I think it's time to start bringing a bit of convergence into play in the greater JS ecosystem.