Yeah, I personally don't mess around with Babel but I imagine you could just take TypeScript's ES6 output and feed it through babel in your gulp/webpack pipeline.

Some people were doing that before TS got async/await compilation directly to ES5 (in TS 2.1). Right now, having Babel in the TS pipeline is not that useful anymore.

I've had some major headaches getting TypeScript to work with Babel and Webpack 2. The main reason I had to use Babel was because I wanted to use Webpack 2's tree shaking feature. Do you know if it's possible to use just TypeScript and Webpack without Babel, and still take advantage of tree shaking?

Honestly this is the main thing keeping me from using TypeScript. I've spent hours, maybe days trying to deal with the mess of Babel/webpack/TS combined with ES6 modules (necessary for tree shaking).

Another problem I ran into was using various packages that weren't typed, but I suppose I can solve that by 'allowing' implicitAny.

I'd really love some advice on this because I want to use TypeScript. It's just been a major headache so far because things are complicated enough with all the other moving parts (Babel presets, import vs require, better but still not well documented Webpack 2, etc.).

«Another problem I ran into was using various packages that weren't typed, but I suppose I can solve that by 'allowing' implicitAny.»

You can keep noImplicitAny and any-type just specific packages that can't/won't be typed. The declaration is now as simple as:

    declare module 'path/to/module-name'

Typescript will any type modules that you declare that way. You can also use star (*) and star-star wildcards in the module name.

Oh, that's great! Is that a recent change? I remember circumvrenting my issues with 'declare module' but it was more involved than just one line.

Yes, simpler module declaration is relatively recent to Typescript having arrived in Typescript 2.0 (released in September).

It's very useful if you want to use native APIs that arrived with es6: Promise, Map etc. TypeScript doesn't shim those

Yeah, that's what I use with Webpack. It's just one more rule on Webpack config, so no reason not to do it. There's many things that are out of scope of TS that are better handled by Babel (like embedding corejs methods based on target browser versions).

If you're using Webpack is it possible to gradually opt files into TS type checking _without_ having to rename them, since you can specify which filename patterns loaders apply to?

It might be worth checking ts-loader or awesome-typescript-loader. I'm not sure how it detects js vs ts in those pipelines. TypeScript can also "compile" JS to check for syntax and other errors, so it may still be extension based. An interesting scenario though.

I believe you might be able to with --allowJs, but to be quite honest I haven't done so. All my projects were TypeScript-based from the start, even if sometimes I end up using JS dependencies.