Maybe this responsibility doesn't fall on tsd but I'm wondering if it should since I see Sindre Sorhus has a lot of projects that use it without any tsconfig, and tsd's defaults are getting kind of outdated since the ecosystem is moving to pure ESM.
In a package's .d.ts files for ESM modules, imports and export from statements with relative paths should have explicit file extensions. If not, then consumers will get errors if they use "moduleResolution": "nodenext".
But tsd doesn't catch problems like this. I tested it out by cloning sindresorhus/file-type, and changing the first line of index.d.ts to
- import type { FileTypeResult } from "./core.js";
+ import type { FileTypeResult } from "./core";
tsd still passes, but it should report an error. Errors from misconfigured pure ESM packages can be confusing, especially if using the default "skipLibCheck": true option. So it would reduce churn if tsd could report these errors by default.
It seems to me like tsd should check all ESM files with "moduleResolution": "nodenext" by default?
Maybe this responsibility doesn't fall on
tsd
but I'm wondering if it should since I see Sindre Sorhus has a lot of projects that use it without any tsconfig, andtsd
's defaults are getting kind of outdated since the ecosystem is moving to pure ESM.In a package's
.d.ts
files for ESM modules, imports and export from statements with relative paths should have explicit file extensions. If not, then consumers will get errors if they use"moduleResolution": "nodenext"
.But
tsd
doesn't catch problems like this. I tested it out by cloningsindresorhus/file-type
, and changing the first line ofindex.d.ts
totsd
still passes, but it should report an error. Errors from misconfigured pure ESM packages can be confusing, especially if using the default"skipLibCheck": true
option. So it would reduce churn iftsd
could report these errors by default.It seems to me like
tsd
should check all ESM files with"moduleResolution": "nodenext"
by default?