Support compile targets between ES5 and ES6

[LPGhatguy]

As of August, 2015, there are several platforms that have JS implementations falling somewhere between ES5 and ES6. Chrome 45+ has block scoping, fat-arrow functions, Map/WeakMap/Set/WeakSet, and classes. io.js 3.x has all of these features as well except fat-arrow functions, but they're coming in Node.js 4.0 or so next month.

The big common case here is that none of these platforms support ES6 modules yet -- I imagine none of them will for some time.

Can we get a compiler mode to emit ES6 features selectively, or at least emit ES6 except for modules? @mhegazy mentioned in the TypeScript gitter that this would be effectively supporting --t es6 alongside --m commonjs in terms of compiler flags.

[vilicvane]

👍

Though you may try something like System.js, for now.

[LPGhatguy]

Well, System.js is a partial solution -- it's just another package manager in the end. The primary reason for wanting this feature, node supporting a good deal of ES6, makes CommonJS the only reasonable target.

[kitsonk]

I would think decoupling packaging emitting from other features would make sense... I see situations where there is a valid use case for emitting UMD/AMD/CommonJS modules while still targeting ES6 at the code level without additional build steps. 👍

[lhecker]

As a feature this would be single most important thing for me right now, since I could effectively use type annotations while using all the ES6 features available in io.js. 👍

[LPGhatguy]

I'd like to note that this is technically possible right now with some rough edges with module resolution if you chain TS by compiling it to ES6 then running it through Babel with only the module transformer enabled. There could be other issues, and I'm not sure how TypeScript handles ES7 translation features either.

Actually, with ES7 coming up I think it's going to be more and more important to selectively enable future JS features as different platforms enable varying support. We're not going to get modules for awhile, but what about annotations from ES7? Async/await? Some of these things could be implemented by some platforms and those features should be used on clients like io.js where the requirements are known ahead of time.

[lhecker]

On the other hand a mode, where you simply write the "near-ES6" syntax of your platform using the e.g. CommonJS syntax (io.js), but treating files which use this syntax just like they are ES6 modules, would be possible too (for me atleast) - all the transpiler would need to do is to basically strip out the TypeScript-specific features.

Currently, if you try to do this, it won't work since the compiler treats "local" variables automatically as global ones, if the ES6 module syntax isn't used, and when using e.g.

const foo = require("./foo");

in more than one file it will throw

error TS2451: Cannot redeclare block-scoped variable 'foo'.

[jbrantly]

@lhecker I think that just means you're not specifying --module if I'm understanding you right.

You can use --target es5 --module commonjs and write import foo = require('./foo').

[lhecker]

@jbrantly Nope that's not what I meant.

What I was saying is that an alternate solution for now would be to mark all files using require() or exports as ES6 modules, thus making file-local variables actually local to the file (which would match CommonJS behaviour and not the current Browser-like one).

That way you could at least already use the latest native ES6 features of io.js (--target es6), without automatically adding shims you don't need. One could also introduce a new target value to supress accidential shims (e.g. --target native) and enforce the use of native ES6 features, but I guess the thing I mentioned in the previous paragraph is much more important.

[jbrantly]

@lhecker I think I see what you're saying. You're specifying --target es6 because you want the es6 emit, but you can't use import foo = require('./foo') in that case, so you're skirting around that by not using import but then running into the scope issue.

You could always use IIFEs 😄

I'm not sure how I feel about this issue overall. If you're targeting the browser then you're going to have to target the least common denominator anyways, which means es5 (and a bring-your-own module system). If you're targeting a server environment where you control everything, sure, you might be able to use some ES6 features that you don't want to transpile but what is the harm in transpiling anyways? Or, alternatively, emit ES6 from TypeScript and use something like Babel whose core competency is transpiling to get CommonJS (whereas TypeScript's core competency is static type checking). I think TypeScript currently does a good job balancing transpiler features and simplicity with the es5 and es6 targets.

[LPGhatguy]

@jbrantly it could also be possible to target only a specific subset of browsers.

Additionally, transpilation kills the benefit of some structures, like numeric for loops with block-scoped variables:

for (let i = 0; i < 10; i++) {
    // ...
}

TypeScript also has issues with for-of loop code generation because of the compile-time ambiguity and the way iterators work. io.js doesn't have that issue, and I'd like to iterate over arbitrary iterables, which would require ES6 output.

[yortus]

This would be great.

Another pain scenario at present is trying to use ES6 generators, which are supported by both TypeScript and Node.js. However if one targets ES5 for Node.js projects, TypeScript won't allow the generators even though it could just emit them as-is (like it does for ES6) if some flag would allow.

One can wait for TypeScript to implement down-level emit for generators in ES5, but that seems unnecessary since the target platform supports generators natively.

I'm aware one can target ES6 and add Babel to the build process, however given that TypeScript can already emit generators, if feels like unnecessary complexity.

More granular targetting in TypeScript would be a great solution IMO.

[plantain-00]

This would be great.

1.4 seems support -m commonjs -t es6 already, but 1.5 does not.