Make import fix for 'export =' respect module target and allowSyntheticDefaultImports/esModuleInterop

[andrewbranch]

Fixes #31219

The change here is super simple. For an export assignment (export = foo):

• if you have allowSyntheticDefaultImport or esModuleInterop enabled, prefer import foo from "foo"
• else if your module target is ES2015+, prefer import * as foo from "foo". (This is invalid, but so is literally anything else with this combination of export form and compiler options, and this one gives the best error message.)
• else, continue using import foo = require("foo") (what previously happened for all cases)

It is possible to use import * as foo from "foo" for some additional cases, but I wanted to get clarified feedback on exactly which cases. My understanding is that, assuming allowSyntheticDefaultImport/esModuleInterop is disabled, export assignments roughly fall into three logical categories:

1. Things that can only be imported with import foo = require("foo"): includes classes, interfaces, types, enums. (From reading old docs, it sounds like this used to be the only category—export = mandated import foo =, bar none.)
2. Things that can be imported with import * as foo from "foo" within ES module spec compliance: includes values that are not callable/constructable.
3. Things that can be imported with import * as foo from "foo" but apparently violates ES module spec: values that are callable/constructable. (E.g. import * as express from "express"; express() works today, but I think it didn’t at some point in the past, because it‘s technically wrong?)

There’s a lot of history here that’s not particularly well-documented as far as I can find—calling on @DanielRosenwasser to help unearth the archives and advise.

[weswigham]

but I think it didn’t at some point in the past, because it‘s technically wrong

Way back when import * as f from "whatever" was first added, the decision was made to allow importing anything "namespacey", since it's a namespace import, after all. And given our downlevel emit (it just becomes var f = require("whatever")), even that was technically not required. Time passed and the es6 module specifications (which does not allow for a callable/constructable/whatever namespace) started getting worked into the community, reality sets in, and we realize that because we have class/function/namespace merging, we allow the import of "namespacey" constructs which shouldn't work, per spec (whereas with our normal downlevel it's fine). Thus the esModuleInterop flag came to be - it modifies our emit to do export hoisting like babel does and like node has occasionally been proposed to do, and likewise strips call/constrct-ability from the namespace in the typechecker to reflect the change in emit.

[andrewbranch]

@weswigham but namespace imports of callable things are still allowed even without esModuleInterop, which is the primary source of my confusion: when/why did that happen, because it seems to be independent of esModuleInterop entirely?

[weswigham]

but namespace imports of callable things are still allowed even without esModuleInterop

Precisely. It's only with the esModuleInterop flag that we flag them as an error (because back compat).

[andrewbranch]

Ah, got it. So I think the question remains: given an export = someValueNotAType, and you don’t have esModuleInterop or allowSyntheticDefaultImports, would we rather write your import as import...require or an import * as?

[RyanCavanaugh]

would we rather write your import as import...require or an import * as?

If there's an export = , then import / require should always be preferred. Anything that is an ES6 module could have been written with export =, so the export = implies a CommonJS module (this is not a 100% reliable heuristic, but it exists)

[andrewbranch]

If there's an export = , then import / require should always be preferred.

@RyanCavanaugh That’s the current behavior—but the issue (#31219) is that import/require is invalid for es2015+. At the very least, if you are targeting es2015+ and have esModuleInterop/allowSyntheticDefaultImports, you should get import foo from 'foo', because it’s the only thing that will compile.

I suppose for <es2015 it’s debatable—I can undo my changes for those cases.

[andrewbranch]

This PR now only changes the behavior when esModuleInterop/allowSyntheticDefaultImports is on—it prefers the default import in that case.

[orta]

Fixes #29038

[andrewbranch]

This PR now only changes the behavior when esModuleInterop/allowSyntheticDefaultImports is enabled and module is ES2015+.

[andrewbranch]

The conversation around this PR has just gotten too confusing—I initially didn’t realize that import ... = require(...) was being inserted in JavaScript, so there was more to do than I thought. I’m closing this and re-opening a fresh PR to explain the approach from a clean slate, even though the code is the same.