ES6 module declarations should be marked to exclude them from `allowSyntheticDefaultImports`

[mattmccutchen]

This is the restated #27293. CC @ryanelian

TypeScript Version: master (471bc64)

Search Terms: esModuleInterop allowSyntheticDefaultImports error undefined default import export

Code: In the b subdirectory, compile with tsc -b . and run with node index.js.

// tsconfig.common.json
{
    "compilerOptions": {
        "composite": true,
        "declaration": true,
        "target": "es6",
        "module": "commonjs",
        "esModuleInterop": true
    }
}

// a/tsconfig.json
{
    "extends": "../tsconfig.common.json",
    "files": [
        "index.ts"
    ]
}

// a/index.ts
export const foo = 42;

// b/tsconfig.json
{
    "extends": "../tsconfig.common.json",
    "references": [
        { "path": "../a" }
    ],
    "files": [
        "index.ts"
    ]
}

// b/index.ts
// Actual: compile OK.  Expected: compile error.
import A from "../a";
// Actual: runtime error.
console.log(A.foo);

Expected behavior: The generated a/index.d.ts uses some new syntax to mark the module as an ES6 module, so allowSyntheticDefaultImports does not apply to it and the default import in b/index.ts is a compile error.

Actual behavior: allowSyntheticDefaultImports applies to module a, so at compile time, the default import is accepted and resolves to the entire module, but at runtime, A.foo raises an error:

REDACTED/b/index.js:7
console.log(a_1.default.foo);
                        ^

TypeError: Cannot read property 'foo' of undefined

Playground Link: N/A, multiple files

Related Issues: #27293

[weswigham]

Please note: The marker actually already exists, we just don't emit it. If the declaration file has export const __esModule: true, then we're guaranteed to treat it like a module and not create a synthetic namespace in the typesystem.

[mgroenhoff]

I am running into this issue as well

[Shingyx]

I'm running into the same issue. I think one way to fix this is to update the __importDefault tslib helper to be a bit more lenient? I'm not 100% sure if this is the behaviour we want though.

I.e., update https://github.com/Microsoft/tslib/blob/ca03390c0bcf14ae0ef8090dec52de5059ed2e96/tslib.js#L220-L222 from

return (mod && mod.__esModule) ? mod : { "default": mod };

to

return (mod && mod.__esModule && mod.hasOwnProperty("default")) ? mod : { "default": mod };

[Shingyx]

As discussed in microsoft/tslib#64, the workaround I suggested above is not the right solution to this problem.

[fregante]

For anyone running into this issue: it's the wrong approach.

The mistake is that you're using import X from 'module' when module does not have a default import. import X does not work like const X = require()

Solution: either use:

import * as X from 'module'

or maybe import it as a CJS module with:

import X = require('module')

The bug is that the compiler should throw an error, not that it doesn't work at runtime.

[rdhelms]

@fregante Thank you so much for your direct summary - I was dealing with a confusing case where import X from 'module' had previously been working, and then after updating dependencies we were having to use const X = require('module') but losing the module's typings...I totally forgot about the import X = require('module') syntax, which is exactly what we needed to import this particular module properly and maintain correct typings 💯