adding ESM type declarations #269
Conversation
Fixes alexreardon#267 When consumers use `"type": "module"` with `"module": "node16"` and `"moduleResolution": "node16"`, the `export default` declaration in `memoize-one.d.ts` is considered invalid because those types are interpreted strictly as CommonJS. The solution here is to create a separate type declaration file called `memoize-one.d.mts` with the same contents. The `.mts` extension is the key here, since it allows the `export default` to be interpreted correctly as ESM. I've also added an `exports` declaration to the `package.json` to point ESM-aware consumers to the correct types. Since all existing code and types are the same, this change should be fully backward-compatible.
|
Thanks for taking a stab at this. I don't think this fix is sufficient. If I run Are the Types Wrong via It's been my experience that it's very tricky to get a single .d.ts file that will work for both CJS and ESM when default exports are used (because TS + CJS really wants to use that |
|
Hmm. I was hoping to just make a small change here; this PR is sufficient to satisfy tsc in the ESM project I was working on. But, I can understand wanting to satisfy |
2 participants
Fixes #267
When consumers use
"type": "module"with"module": "node16"and"moduleResolution": "node16", theexport defaultdeclaration inmemoize-one.d.tsis considered invalid because those types are interpreted strictly as CommonJS.The solution here is to create a separate type declaration file called
memoize-one.d.mtswith the same contents. The.mtsextension is the key here, since it allows theexport defaultto be interpreted correctly as ESM.I've also added an
exportsdeclaration to thepackage.jsonto point ESM-aware consumers to the correct types.Since all existing code and types are the same, this change should be fully backward-compatible.