Import named `default` is typed differently than default import (with moduleResolution: node16)

[calebeby]

Bug Report

🔎 Search Terms

default import, default export, named default export, module resolution, node 16

🕗 Version & Regression Information

Version 4.7.3

I also tried nightly, it is present there too.

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about default imports/exports
• I was unable to test this on prior versions because they didn't have the node16 setting

⏯ Playground Link

Can't use playground because it requires multiple files.

https://github.com/calebeby/ts-import-bug

💻 Code

In node, mod2 and def are the "CJS namespace import" as described in the Node docs.

import mod2, {default as def} from 'foo'

// TS thinks this is false; it is actually true
console.log(def === mod2)

// TS thinks this works but it doesn't (at runtime def === mod2)
def()

foo.d.ts:

export declare function def(): void
export default def

If I switch moduleResolution to node, mod2 and def have the same type (not matching node's native ESM behavior, but that is expected since moduleResolution is not set to node16)

🙁 Actual behavior

a.mts:11:13 - error TS2367: This condition will always return 'false' since the types '() => void' and 'typeof import("/Users/calebeby/Projects/ts-import-bug/foo/foo")' have no overlap.

🙂 Expected behavior

def and mod2 should have the same type (the CJS namespace). TS should say that the def() line is an error. def === mod2 should not say This condition will always return 'false'

[weswigham]

Hm, I'm guessing we're missing the logic we use for resolving default imports on named-imports-named-default. Should probably unify those codepaths.

[calebeby]

I have some more information - it seems related:

If foo points to a .cjs file / not type:module:

foo.cjs

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.def = void 0;
function def() { }
exports.def = def;
exports.default = def;

import mod2, {default as def} from 'foo'

In node:
mod2 and def are both the module object like { def: ..., default: ... }

In TS:

mod2 is the module object like { def: ..., default: ... }, def is the function.

---

If foo points to a .mjs file / type:module:

foo.mjs

export function def() {}
export default def

import mod2, {default as def} from 'foo'

In node:
mod2 and def are both the function

In TS:

mod2 is the module object like { def: ..., default: ... }, def is the function.

---

It seems like TS needs to read the .d.ts differently depending on whether the actual import resolves to a cjs or mjs (since that's what Node does).

[weswigham]

Oh, I misread the repro initially -

    "module": "ESNext",
    "moduleResolution": "Node16",

is a questionable configuration. module: node16 or module: nodenext replicate node's import behavior - module: esnext with moduleResolution: node16 is some weird browser/bundler configuration without really great specs on its behavior. Specifically, it's behavior is mostly "whatever we used to do for module: esnext but with export map traversal", and not "what node actually does".

You probably wanna set module: nodenext - checking for the node cross-format default import interop behavior is gated behind the module flag, not the moduleResolution one.

[calebeby]

@weswigham In the repro repo I switched module to NodeNext and it still has the same issue

[weswigham]

Ah, you're right, my initial assessment was right; I was just thrown off by the incorrect compiler option. It's probably worth noting that this divergent behavior between the two kinds of default imports checking-wise can also be observed in older emit modes just using esModuleInterop.