Closed ChristopherChudzicki closed 1 year ago
This is a great addition. Just one comment... from the blog post, it seems to my untrained eye like it wants the entry to look like this:
".": {
"import": {
"types": "./build/esm/types.d.ts",
"default": "./build/esm/index.js"
}
}
is that right? I see you started to type " it's example is a little more involved than what" so that probably explains the discrepancy.
Heh, I was wondering if you were going to ask about that!
I do not understand why this would be necessary, but the example in TS blog seems to be specifying different TS declaration files for the ES Module and CommonJS versions of the package—.d.ts
for ESM, .d.cts
for CJS. Again, I don't really understand why you'd need different type declarations. Likely something to do with default exports.
The syntax in this PR should be OK. The TS docs show this sort of syntax here:
I did just force push a swap to the order of "types" and "imports", because the docs say things like:
// Entry-point for TypeScript resolution - must occur first!
a statement which boggles my mind, since json.org says "An object is an unordered set of name/value pairs."
Yeah that is nuts, I didn't know what to think there. I saw the same requirement on a react library today that depends on prop order to build a matrix transform. Feels like a very confusing debug situation waiting to happen!
Sounds great btw, merge away.
This change allows Typescript to find type definitions when using the
exports
field, which is used when tsconfig'smoduleResolution
is set tonode16
.See:
exports
. https://devblogs.microsoft.com/typescript/announcing-typescript-4-7/#package-json-exports-imports-and-self-referencing it's example is a little more involved than what