Support 'target':'es5' with 'module':'es6' to allow dead code elimination

[SynerG]

The import/export statements used in ES6 modules allow tools such as Webpack and Rollup.js to eliminate all the code from unused exports. (For example, see Dr. Axel Rauschmayer's post on this topic)

However, targeting ES5 remove the import/export statements, so these tools cannot remove unused exports.

TypeScript 1.7 included 'es6' and 'es2015' as valid options for the 'module' setting, but the following config:

// tsconfig.json
{
  "compilerOptions": {
    "module": "es6",
    "target": "es5"
  }
}

Produces this error:

error TS1204: Cannot compile modules into 'es6' when targeting 'ES5' or lower.

So, it looks like it is not currently possible to generate ES5 code while retaining the import/export statements of ES6 modules.

This is related to issue #4692 that proposes enabling more granular targeting beyond 'ES5' or 'ES6', but in this particular case the two required options already exist in tsconfig.json ('target' and 'module'), but the particular combination of values ('target':'es5', 'module':'es6') doesn't work.

[pkozlowski-opensource]

Also see #5806 and #5790

[SynerG]

@pkozlowski-opensource thanks for the two relevant related issues.

#5806 presented the same issue, but it was closed in favor of #5790 to prevent redundancy.
But #5790 was closed prematurely because the initial post was not clear enough and was misinterpreted as trying to transpile ilegal ES6 code.

(#5790 contains relevant discussion on the topic. The real issue was clarified after being closed. @weswigham stated that 'if enough people see a need for it, we could conceivably support the configuration - it's just not something our emitter currently expects to need to do' and @kitsonk said that 'there is no harm in emitting ES5 code in ES6 module format (though my opinion is far from official)'. The issue also mentions that UglifyJS and Google Closure Compiler do not implement the same tree-shaking capabilities of Rollup/Webpack 2)

So, the 2 previous issues were closed for reasons beyond the issue itself.
But there is not possible yet to transpile to ES5 using ES6 module syntax, or combine TypeScript with tree-shaking tools that remove unused exports (Webpack 2/Rollup) without requiring another tool such as Babel.
I will keep this issue open for now. (#5790 could be reopened to keep the old discussion).

[frankwallis]

This issue currently prevents using the systemjs-builder rollup support unless you also use babel in the pipeline to output es6 modules with es5 code. See frankwallis/plugin-typescript#97 (comment)

So +1 from me, thanks.

[JabX]

👍

Another issue for me is that Typescript's module resolution is pretty much only compatible with true ES6 modules, which means that using good old CommonJS modules (like from npm) is problematic when you want to get the default export of one of those modules. The workaround is to import them as import * as module from 'module', but it's against the ES6 standard and doesn't work well with module definitions.

This means that if using this workaround isn't acceptable (in my case it is, so I'm fine), you are today forced to compile to ES6 and chain with Babel to transpile everything, whereas you could have simply compiled your ES6 to ES5 with Typescript and used Babel's module transform (or even directly Webpack 2 that works the same).

[mhegazy]

@JabX consider using --allowSyntheticDefaultImports, if you are sure the module you are importing has a default export. see https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#support-for-default-import-interop-with-systemjs

[JabX]

@mhegazy That flag is only about getting the type definitions right. The problem lies in the transpiled code.

Writing import Module from 'module' will generate something like var Module = require('module').default, whereas import * as Module from 'module' generates var Module = require('module').

These are not the same, and only the second works with CommonJS.

[frankwallis]

You can also use:

import module = require('module');

to import commonjs

[JabX]

I know about this syntax, but you can't use it in JS files, which I also transpile using Typescript. I should have said so earlier.

[guybedford]

This is critical to the Rollup integration with TypeScript. In the eventual future as well, when ES modules are supported natively, this option will have become the default output, so there is no risk to implementation as it will be needed one day anyway.

[guybedford]

Oh I see module: es6 + target: es6 will work, so scratch the above argument. Still important for Rollup support though!

[texastoland]

I'm currently doing TS -> ES6 -> rollup -> ES5 via tsc. (source)

I can't find the justification why we should compile twice in order to use a separate bundler?

Edit: partially works using the Compiler API. @Victorystick implemented a workaround) for export class.

$ node -e 'const ts=require("typescript");console.log(ts.transpileModule("export const cube=x=>x*x*x",{reportDiagnostics:true,compilerOptions:{module:ts.ModuleKind.ES2015}}))'
{ outputText: 'export var cube = function (x) { return x * x * x; };\n',
  diagnostics: 
   [ { file: undefined,
       start: undefined,
       length: undefined,
       messageText: 'Cannot compile modules into \'es2015\' when targeting \'ES5\' or lower.',
       category: 1,
       code: 1204 } ],
  sourceMapText: undefined }

$ node -e 'const ts=require("typescript");console.log(ts.transpileModule("export const cube=x=>x*x*x",{compilerOptions:{module:ts.ModuleKind.ES2015}}))'
{ outputText: 'export var cube = function (x) { return x * x * x; };\n',
  diagnostics: undefined,
  sourceMapText: undefined }