Support Typescript 4.7 "Node16" extension requirements

Description

With Typescript version 4.7, Typescript now has the option to preserve “ES Modules” if tsconfig.json specifies:

{
  "compilerOptions": {
    "module": "Node16"
  }
}

This is a step forward in supporting native ESM in Node from Typescript’s direction, but it comes with the requirement that all typescript modules when imported use the .js extension.

Ref: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-7.html

This works all fine and well in Vite when importing typescript modules in .ts-files.

The problems begin when importing .ts-files in .js, .vue, .svelte, and so on.

E.g.

// ./some-ts-file.ts
export const hello = "Hello";

// ./my-app.js
import { hello } from "./some-ts-file.js"

See reproducible example: https://github.com/aMediocreDad/vite-import-ts-as-js

Suggested solution

The expectation is that importing .ts-files as .js resolves the file like it does in .ts-files at the moment (See related “Closed” issue: https://github.com/vitejs/vite/issues/3040).

Alternative

No response

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn’t already an issue that request the same feature to avoid creating a duplicate.

[bluwy]

We’ve discussed this in the last team meeting and decided to support .js -> .ts resolving for JS files too based on the related tsconfig.json/jsconfig.json that has the special resolution setting.

The rule seems to be that, if the moduleResolution is node16, nodenext, or above; Or else if the module is node16, nodenext, or above; Then we’d kick in the file resolution.

[aMediocreDad]

Out of curiosity, did you notice improvements? Runtime or Buildtime?

I have not tested for any build/runtime improvements. However, it does provide some long awaited developer experience improvements.

Using the “Node16” module specifier makes Typescript finally use the import/export fields in package.json properly. This is a big help where packages don’t use the “main” field because they do not want to indicate backwards compatibility with pre Node 12. Previously, Typescript tooling was usually difficult to set up because of how it failed to recognize newer package.json configurations (that only cater to ESM).

I do not use the tsc compiler so I won’t see the improvements that the compilation options provide. But the steady move towards proper ESM handling across all tools commonly used in the same toolchain is all I really want to see.