"moduleResolution": "NodeNext" throws ESM related errors

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.69.2
• OS Version: macOS 12.4
• TypeScript Version: 4.7.4

Steps to Reproduce:

• Create an npm package. Install typescript@4.7.4 and pretty-ms.
• Set tsconfig.json as:

{
  "compilerOptions": {
    "target": "esnext",
    "lib": ["dom", "esnext"],
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "module": "NodeNext",
    "moduleResolution": "NodeNext"
  },
  "include": ["./src/**/*"]
}

• Add "type": "module" in package.json
• Following error messages are displayed by VSCode in a file with .ts extension under src/:

// Cannot find module 'pretty-ms' or its corresponding type declarations. ts(2307)
import ms from "pretty-ms";

// The 'import.meta' meta-property is not allowed in files which will build into CommonJS output. ts(1470)
console.log(import.meta.url);

• tsc throws no errors.
• Change below values intsconfig.json

{
  "module": "esnext",
  "moduleResolution": "node"
}

• VSCode no longer throws any errors.

[egasimus]

The main issue with ESM and nodenext/node16 mode is TypeScript refusing to add .js extensions to the generated import statements in the compiled files.

The officially proposed workaround is to manually add .js extensions in the TypeScript sources, which is particularly graceless. So .ts extension is disallowed, yet .js extension is required in order to point to a .ts file - what the fuck? And where do .d.ts files even fit into this?

It’s particularly surprising because TypeScript encourages you to use import and export statements even when compiling to CJS. And when you combine this broken behavior with Node’s half-assed effort to push people off CommonJS and onto ESM, this hits real hard if you’re using monorepos/workspaces/submodules/writing a library.

Frontend framework users whose build toolchain compiles TypeScript on demand will be hit next as they add the .js extensions and their code stops updating. Frameworks will have to special-case this kludge and it’ll become 10x harder for a newcomer to understand how JS modules work.

It makes my team members develop an aversion to TypeScript, not to mention it probably got me looking pretty bad myself, because the only way to perform the otherwise trivial act of delivering an isomorphic library (i.e. one which which works out of the box in all contexts - Node, browser, ESM, CJS, pre-compiled, on-demand, framework, no framework) is walking the compiled code’s AST to add the extensions.

[kachkaev]

I’m facing the same issue in these two PRs:

• https://github.com/kachkaev/njt/pull/186
• https://github.com/blockprotocol/blockprotocol/pull/709

Here are some third-party packages that have problems with default exports when "moduleResolution": "NodeNext" or "moduleResolution": "Node16":

• ajv
• styled-components
• algoliasearch
• next/link, next/document, next/image, etc.
• react-slick
• @mui/icons-material/*
• react-gtm-module
• @emotion/cache
• react-html-parser
• slugify

As a temp solution, I’ve managed to do this:

-import x from "x";
+import _x from "x";
+const x = _x as unknown as typeof _x.default;

Although it‘s true that the problem is within the packages, I wonder if it is possible to create a new compile option which could be used during the transition period? Something like allowSyntheticDefaultImports, but for a different use case.

When switching a project to "moduleResolution": "NodeNext", it’s much easier to negotiate one extra line in tsconfig.json than a lot of import _x from "x" hacks. Waiting for upstream fixes may take a while and slow down migration to ESM.