Always treat .d.*.ts files as commonjs-format modules for the purposes of import interop#59622
Always treat .d.*.ts files as commonjs-format modules for the purposes of import interop#59622weswigham wants to merge 3 commits intomicrosoft:mainfrom
.d.*.ts files as commonjs-format modules for the purposes of import interop#59622Conversation
weswigham
added
Breaking Change
typescript-bot
added
Author: Team
For Milestone Bug
|
With export const class1: string;
export const class2: string;With this change, it becomes legal to import that file like import css from "./styles.css";when in fact no default import will be synthesized by the runtime since the loader exposed it as a real module. If we had any precedent for doing something like this, maybe it would be nice to assign the module kind based on module syntax (CJS for I think this will work alright and is better than the status quo, but I can see us needing to revisit it if some third-party framework begins making really heavy use of |
3 participants
Fixes #57229
The way
allowSyntheticDefaultImports/esModuleInteropandmodule: nodenext's"type": "module"detection interplay in the context of.d.*.tsfiles right now is... confusing. Since they are.tsfiles, they do currently get assigned apackage.json-type-dependent module kind, which determines if the module is made available as adefaultor not on an esm import, and if a cjs file can import it at all, and furthermore we have heuristics involving the presence of adefaultin the declaration file which can then disable the syntheticdefaultcreation for interop'd imports (import statements in cjs format files undermodule: nodenext).This menagerie of behaviors means that to write a declaration file for a json file similar to
["foo", "bar"], so is no single way to write it that works for all callers, in all package type contexts, even though json imports (or any non-js import) are not package type dependent.On investigation, I find this state of affairs confusing.
This PR changes how we interpret
.d.*.tsfile module formats to always be cjs-like. This means the correct way to write the declaration file for["foo", "bar"]is alwaysand registers as importable by all import and require constructs in all package type contexts.