export [default] class A {} generates invalid ES6 module code

[Victorystick]

Running TypeScript version 1.7.4 (the Playground version) with the following options

ts.transpileModule(..., {
  compilerOptions: {
    target: ts.ScriptTarget.ES5,
    module: ts.ModuleKind.ES6
  }
}).outputText

yields incorrect outputs in these two situations:

export class A {}
export default class A {}

// results in these snippets, respectively

var A = (function () {
    function A() {
    }
    return A;
})();
A = A;
var A = (function () {
    function A() {
    }
    return A;
})();
exports.default = A;

when I'd expect

export var A = (function () {
    function A() {
    }
    return A;
})();
export default (function () {
    function A() {
    }
    return A;
})();

Oddly enough, this seems to work as expected:

class A {}
export { A };
export default A;

// generates

var A = (function () {
    function A() {
    }
    return A;
})();
export { A };
export default A;

(See rollup/rollup-plugin-typescript#9 for the original discussion.)

[Victorystick]

This may be related to #5594, and possibly (at least partially) fixed by #5648 (solves the opposite case; ES6 code with pre-ES modules).

[vladima]

note that original example is not legal ES6 code: export default class A {}introduces export named default as well as local name A which will collide with class A declared above. Your workaround is actually the right way to go, alternatively you can use:

export default class A {}
export {A}

or

export class A {}
export default A

[Victorystick]

I wasn't being clear enough. What I meant is that

export default class A {}

transpiles to

var A = (function () {
    function A() {
    }
    return A;
})();
exports.default = A;

although the target module syntax is supposed to be ES6, where you'd expect something like

var A = (function () {
    function A() {
    }
    return A;
})();
export default A;

to be generated. TypeScript is mixing CommonJS with ES2015 although the latter was requested.

[vladima]

This scenario is not supported, attempt to compile this code from the command line yields

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

transpile* currently reports only syntax errors (assuming that other errors are semantic and thus cannot be 100% trusted) however I think we should report errors that are produced during compiler option validation - #5798 tracks this.

[vladima]

update: we correctly fill diagnostics property on the output result if reportDiagnostics on input transpileOptions is set to true. This code

var ts = require("./built/local/typescript");
var text = "export default class A {}";
var r = ts.transpileModule(text, {
  reportDiagnostics: true,
  compilerOptions: {
    target: ts.ScriptTarget.ES5,
    module: ts.ModuleKind.ES6
  }
});
console.log(r)

yields

{ outputText: 'var A = (function () {\n    function A() {\n    }\n    return A;\n})();\nexports.default = A;\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 }

[weswigham]

Though 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.

[Victorystick]

@vladima Thanks for reportDiagnostics; I was missing that.

@weswigham Is there any reason not to allow ES2015 modules with an ES5 or ES3 compile target? Practically all other configurations seem to be supported. Such a configuration should allow Rollup to bundle TypeScript apps, without having to rely on a separate pass just to transpile the generated ES2015 code to ES5.

I've modified emitter.ts to emit ES2015 export code for classes. While I'm not very familiar with TypeScript's test suite, I could try to add some tests for it.

[pkozlowski-opensource]

Though 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.

@weswigham IMO there are 2 options:

• ES6 modules are supported for ES5 target and we can use external packagers / tree-shakers
• TypeScript provides build-in packager with tree-shaking capabilities.

I don't know what is easier from the technical point of view nor what is TS longer-term strategy / vision for packaging / bundling / tree-shaking but IMO splitting those efforts and let external bundlers do the job might be a way to go.

[kitsonk]

• TypeScript provides build-in packager with tree-shaking capabilities.

Outside of the potential of bundling, as far as the tree-shaking, that is specifically against the design goals of TypeScript and been discussed before and likely won't ever arrive.

• ES6 modules are supported for ES5 target and we can use external packagers / tree-shakers

If your external packager / tree-shaker only supported ES6 modules, I would get a different one. I can see the value in outputting ES5 code in an ES6 module format, but I can't think of a single mainstream module loader that only supports ES6 modules, because there is not agreement on the ES6 module loading semantics. So I see it as a nice to have at this point versus a requirement.

Why do you feel that ES6 modules are a barrier to using an external packager / tree-shaker?

[pkozlowski-opensource]

If your external packager / tree-shaker only supported ES6 modules, I would get a different one.

@kitsonk we are talking abut https://github.com/rollup/rollup here. Are you aware of any other packager that does (or at least tries) real tree-shaking?

[kitsonk]

Sorry, I am clearly out of touch with the internet for 6-7 weeks since rollup came into existence. It seems the wheel of re-invention comes around again. I think the assertion though that tree shaking/dead code removal is not unique to rollup. Instead of improving WebPack or Browserify, we go off and invent something new. 😢 (Also with dead code removal/tree shaking coming in WebPack2) Also, its assertion that this can only be done under ES6 module format I find confusing, but oh well... In addition, since MIDs, dependency resolution, etc. are still up in the air as far as ES6, I think it is very risky to adopt ES6 modules as the final state for individual projects at the moment, but that is my opinion.

I do agree with the import syntax of ES6, it does make it a bit easier to identify sub-module unused code.

As far as other tooling that does tree shaking/dead code removal, irrespective of the module format:

• UglifyJS
• Closure Compiler

Admittedly, you need a level of other tooling to create the layers/bundles for your application. Clearly tooling in JavaScript these days is a bit of a challenge.

[pkozlowski-opensource]

@kitsonk I'm too familiar with the lamentable state of ES6 loaders / build tools. But let's not side-track here - the issue here is very specific.

I do agree with the import syntax of ES6, it does make it a bit easier to identify sub-module unused code.

Precisely. And afaik WebPack2 will also work off the ES6 modules.

So the practical question is: how do we feed ES6-modules code into those tools. Of course I could use:
TS -> Rollup (or whatever) -> Babel (or anything that can do ES6 to ES5) but it makes the whole setup even more complex.

Regarding other mentioned tools:

• I don't think that UglisfyJS aims at the same level of tree-shaking as rollup
• from my conversations with people from Google about closure compiler it doesn't seem like it is easy / usable in practice right now