Unable to access properties of namespace from imported package when `moduleResolution: 'NodeNext'`

[ifiokjr]

Bug Report

🔎 Search Terms

• moduleResolution
• NodeNext
• module
• mts

🕗 Version & Regression Information

• This changed between versions 4.6.4 and 4.7.2 as a result of the new "moduleResolution": "NodeNext" setting I have also tested in nightly

⏯ Playground Link

Playground link with relevant code

💻 Code

import is from '@sindresorhus/is';

is.nullOrUndefined('something');
// => Property 'nullOrUndefined' does not exist on type 'typeof import("file:///node_modules/@sindresorhus/is/dist/index")

is.emptyObject({});
// => Property 'emptyObject' does not exist on type 'typeof import("file:///node_modules/@sindresorhus/is/dist/index")'.

🔧 Settings

{
  "compilerOptions": {
    "module": "ESNext",
    "target": "ESNext",
    "moduleResolution": "NodeNext", // This is the change that caused the issue.
    "jsx": "preserve",
    "lib": ["DOM", "ESNext"],
    "noImplicitReturns": true,
    "sourceMap": true,
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "noFallthroughCasesInSwitch": true,
    "forceConsistentCasingInFileNames": true,
    "allowUnreachableCode": false,
    "strict": true,
    "resolveJsonModule": true,
    "useDefineForClassFields": true,
    "importsNotUsedAsValues": "remove",
    "noUncheckedIndexedAccess": true,
    "noImplicitOverride": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "pretty": true
  }
}

🙁 Actual behavior

Importing from this module which exports the namespace is as its default export doesn't recognize any of the properties within the namespace.

🙂 Expected behavior

It should allow for access to the members of the namespace.

[ifiokjr]

It doesn't seem to have anything to do with namespaces. I'm seeing the same issue with recursive-copy.

Playground

import copy from 'recursive-copy';

copy('', '', {})
// => This expression is not callable. Type 'typeof import("file:///node_modules/recursive-copy/index")' has no call signatures.(2349)

[Jamesernator]

It doesn't seem to have anything to do with namespaces. I'm seeing the same issue with recursive-copy.

It is because of namespaces, basically in Node ESM the default export will always be the namespace module.exports.

For example suppose you declare the following CJS module in TS:

// mod.cts
export default function foo() {

}

The compiled code becomes:

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

Notice that this is a namespace with a exports.default = foo field.

If you import this file into ESM in Node:

// main.mjs
import mod from "./mod.cjs";

console.log(mod);

This will print:

{ default: function foo() { ... } }

You may have expected to print the function itself, but no, when importing CJS into ESM in Node the default-export is always the namespace.

If you want the above program to print the function itself, you need to use export = in the CJS file, i.e.:

// mod.cts

// the ESM file now prints the function itself when importing this module
export = function foo() { }

// Note that "export = ..." is equivalent to
// "module.exports = ..." 

Now what's happening with recursive-copy is basically the reverse, the actual implemention of recursive-copy uses module.exports = copy to define the function.

However the types, use export default copy, which more accurately translates to:

// This is not the same as module.exports = copy
module.exports = { default: copy };

The reason this worked previously is because you're using esModuleInterop which adds a wrapper that actually checks if there is a default export when compiling to CJS.

But this behaviour isn't how Node's ESM support actually works (this was just how TS's ESM -> CJS compiler worked) so it wasn't copied over into "module": "NodeNext".

It would probably be plausible to add another tsconfig option similar to esModuleInterop for this, but the thing is existing libraries that are presuming esModuleInterop might or might not work with such a flag (depending on how their types are written), so it's probably better to just fix the libraries on a per library basis.

[RyanCavanaugh]

@weswigham please confirm and then let's write some docs

[weswigham]

I've added some FAQ entries.

[Jamesernator]

I've added some FAQ entries.

It might be worth mentioning that for people who are authoring CJS that they can use export = instead of export default if that was their intention.

[rsweeneydev]

I think this is a legitimate bug in NodeNext module resolution. What seems to be missing from the Typescript compiler using NodeNext module resolution is the syntax sugar support that Node offers.

import { default as foo } from 'foo';

is equivalent to

import foo from 'foo';

See the Node docs on CommonJS module resolution.

The Typescript compiler doesn't treat those two statements as equivalent like Node does. It would make migrating from CJS to ESM much simpler if it did.

[weswigham]

What seems to be missing from the Typescript compiler using NodeNext module resolution is the syntax sugar support that Node offers.

That behavior is gated on the module flag, not the moduleResolution flag - the resolution flag defines how specifiers resolve and formats are detected, while the module flag handles actually checking imported identifiers (and uses format data setup by the module resolution process). If you set module: nodenext rather than module: esnext, you get the default interop imports you expect.