Proposal: add --hoistImports to compiler options

[ericanderson]

In ES6, imports are hoisted and evaluated before code within the same file. Webpack definitely already does this and I think rollup might too (or certainly it would be legal for them to do so).

Example:

import installPolyfills from "ie-polyfills";
installPolyfills();
import Foo from "other-code";

In ES6, your code will be evaluated as

import installPolyfills from "ie-polyfills";
import Foo from "other-code";
installPolyfills();

and cause an unexpected error (polyfills aren't available for Foo) since in an ES5 engine it still behaves as the example.

Unfortunately, this allows us to write code that doesn't behave the same depending on the output module type (if TS hoisted imports when module: "es6") nor when running ES6 style code through other tools (like webpack or rollup).

This flag would instruct TS to hoist imports in generated code, regardless of the output module format. Thus one can write code that can be sure to behave the same in node 6, webpack, and engines that natively support es6 modules.

Thus, with hostImports: true and module: "cjs", your output code would be:

var installPolyfills = require("ie-polyfills");
var Foo = require("other-code");
installPolyfills();

I think that ideally this flag would default to true when module: "es6" however that would likely be considered a breaking change. So perhaps that change (or always defaulting it to true, since TS looks like ES6) could happen in TS3.

Thanks
CC @mhegazy

[weswigham]

module: "es6" doesn't downlevel any imports - what starts as an import statement ends as an import statement. Do you mean target?

[ericanderson]

Thanks Wesley. Good catch. Updating

[weswigham]

It's also probably worth noting that is is the behavior for all module formats other than cjs.

[ericanderson]

Sorry, now that I am rereading what I wrote. When using webpack with module: "es6", your imports are hoisted (in webpack) because it looks like es6 code.

[weswigham]

Right, but your point is that our behavior differs from spec when module: "commonjs" is set, yeah?

[ericanderson]

If TypeScript is a strict superset of es6, then the code generated when module: “cjs” is not to spec.

Whether or not that’s what TypeScript is, I would like to ensure that my fellow engineers do not accidentally introduce bugs due to side effects when testing via node vs runtime environments.

[DanielRosenwasser]

Wait, is this #16166?

[ericanderson]

Yeah I guess it’s very similar. That’s more about having an error for out of order and this is an option to force hoisted imports even in cjs

[weswigham]

The resolution on the other issue was to commit to changing our cjs emit to hoist imports (not to issue some warning), which would is what we'd do here, too. As I said, it is already how it behaves for every other target.

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.