Should type-only import resolving to ES module from CJS module be allowed?

[ShogunPanda]

Bug Report

🕗 Version & Regression Information

I observed this in TypeScript 4.9.x, couldn't test earlier versions.

💻 Code

tsconfig.json:

{
  "compilerOptions": {
    "allowJs": true,
    "target": "ESNext",
    "module": "CommonJS",
    "outDir": "dist",
    "lib": ["ESNext", "DOM"],
    "esModuleInterop": false,
    "declaration": true,
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true,
    "resolveJsonModule": true,
    "sourceMap": true,
    "moduleResolution": "nodenext",
    "baseUrl": "."
  },
  "include": ["index.ts"]
}

package.json:

{
	"dependencies": {
		"got": "^12.5.3",
		"typescript": "^4.9.5"
	}
}

index.ts:

import type { Headers } from 'got'

const foo: Headers = {}
console.log(foo)

🙁 Actual behavior

Error reported:

index.ts:1:30 - error TS1479: The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("got")' call instead.
  To convert this file to an ECMAScript module, change its file extension to '.mts', or add the field `"type": "module"` to '/Volumes/DATI/Users/Shogun/Programmazione/Test/got/package.json'.

1 import type { Headers } from 'got'
                               ~~~~~


Found 1 error in index.ts:1

Note the got is just a quick repro example. It happening with any ESM module.

🙂 Expected behavior

Since I'm just doing import type, the emitted file has no requires at all and thus the error is unnecessary.

[andrewbranch]

This is a duplicate of #46213, just with an updated error message, but I don’t think the analysis that led us to close #46213 was correct. It’s probably worth reconsidering this.

[ShogunPanda]

Yes, please.
This makes interoperability a mess for module maintainers (like me) and I would like user not to have to use @ts-expect-error everywhere.

Is it hard to suppress the error when doing import type only?

[andrewbranch]

No, it’s not hard, we just have to be sure it makes sense and doesn’t have any other unintended consequences.

[Andarist]

One potential risk is that nominal types could accidentally leak into the project in two versions - one coming from the CJS types and one from the module types. This wouldn't exactly be a new risk but this could make it more common.

I'm not saying that this should be a blocker - being able to use types from modules in CJS type definitions would solve some of my problems. It is an important consideration though.

[fatcerberus]

Isn’t the only truly nominal type in TS unique symbol? afaict all other methods to emulate nominal types in TS (e.g. branded primitives, deferred conditional types, etc.) are still more or less structural insofar as if you define the type twice it will refer to the same type in both places.

[Andarist]

Arent classes with private members nominal?

[fatcerberus]

Oh, good point; yes, they are. Not sure how I forgot about that!

[ef4]

Even if one follows the instructions in the error message and tries to use dynamic-import-type syntax, the error persists:

type Terser = typeof import('terser');
// The current file is a CommonJS module whose imports will produce 
// 'require' calls; however, the referenced file is an ECMAScript module 
// and cannot be imported with 'require'. Consider writing a dynamic 
// 'import("terser")' call instead.

The only workaround I've found is to write a real function that does the dynamic import and infer the types off of that:

async function loadTerser() {
  return await import('terser');
}
type Terser = Awaited<ReturnType<typeof loadTerser>>;

[andrewbranch]

The instructions are telling you to write the latter because the error message doesn’t realize you were writing a type-only import to begin with. But something is still weird with that error being issued on an ImportType (the former) 🤔.