Changing moduleResolution from Node to Node16 throws error

Describe the bug

Trying the Vite React setup on StackBlitz & my local setup, changing the moduleResolution to Node16 throws this error but the server starts and shows the Vite + React page, but it is kinda annoying to have this red highlight on the IDE

Reproduction

https://stackblitz.com/edit/vitejs-vite-qqmddf?file=vite.config.ts&terminal=dev

Steps to reproduce

Change moduleResolution of tsconfig to Node16

System Info

StackBlitz

Used Package Manager

pnpm

Logs

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn’t already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it’s a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[michael42]

That’s because TypeScript supports the exports-field when using "moduleResolution": "NodeNext" or Node16.

@vitejs/plugin-vue (or @vitejs/plugin-react) in your case declares exports like this:

{
  "name": "@vitejs/plugin-vue",
  "version": "3.1.0",
  // ...
  "exports": {
    ".": {
      "types": "./dist/index.d.ts",
      "import": "./dist/index.mjs",
      "require": "./dist/index.cjs"
    }
  }
  // ...
}

When TypeScript resolves this, it reaches the ./dist/index.d.ts. This is not an mts, nor cts, so the package.json-module-field determines the module system. Since that’s not set, it defaults to CommonJS.

And finally TypeScript, loads the index.d.ts with its export { vuePlugin as default, /*...*/ }. But when using CommonJS, exporting something as default does not cause it to be the default export when importing from ESM. module.exports.default = 42 is default-importable, but it’s { default: 42 } at run-time.

As far as I know, the vite plugins would need to provide separate type definitions for CommonJS and ESM to fix that mismatch, like this:

  "exports": {
    ".": {
      "import": {
        "types": "./dist/index.d.mts",
        "default": "./dist/index.mjs"
      },
      "require": {
        "types": "./dist/index.d.cts",
        "default": "./dist/index.cjs"
      }
    }
  }

Or when they are named exactly like this, dropping types would work, too ({"import": "./dist/index.mjs", "require": "./dist/index.cjs"}).

[michael42]

Just looked at it and I’m not sure if that’s the same issue or if I understand Ryan Cavanaugh properly. I do, however, think that TypeScript is correct in that case and there’s a bug in the type definitions.

Consider this example, that defines a CommonJS export named default:

// y.cjs:
exports.default = 1

// y.d.cts:
declare const y = 1
export default y

Importing it with Node.js 18:

import y1 from "./y.cjs"
import * as y2 from "./y.cjs"
import {default as y3} from "./y.cjs"

console.log("y1", y1)
console.log("y2", y2)
console.log("y3", y3)

then prints:

y1 { default: 1 }
y2 [Module: null prototype] { default: { default: 1 } }
y3 { default: 1 }

Which is exactly what TypeScript 4.9.3 with moduleResolution: Node16 infers:

y1 satisfies { default: 1 }
y2 satisfies { default: { default: 1 } }
y3 satisfies { default: 1 }