Generate separate type declarations for CommonJS. #11
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Although these are identical to the type declarations for ESM, it is necessary to generate separate type declarations for CommonJS for compatibility with TypeScript's Node16/NodeNext module resolution modes.
See microsoft/TypeScript#56529
See https://arethetypeswrong.github.io/?p=unknown%400.2.5
See https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/main/docs/problems/FalseESM.md
With this change, TypeScript will resolve the types as follows in Node16/NodeNext modes:
"exports": ".": "require": "./dist/cjs/unknown.js"
, and resolve types to the accompanying"./dist/cjs/unknown.d.ts"
."exports": ".": "default": "./dist/unknown.js"
, and resolve types to the accompanying"./dist/unknown.d.ts"
.Note that it is not necessary to specify
"types"
in"exports"
because TypeScript will follow the node module resolution algorithm to resolve the JavaScript file that would be imported, and then automatically discover type definitions adjacent to that JavaScript file.The top-level
"types"
entry is probably not required for the same reason, but I have left it alone for now for the sake of making a minimal change to solve this problem.Without this change, when importing
unknown
from a CommonJS project with Node16/NodeNext module resolution, TypeScript reports: