Conversation
Done to prevent accidental foot-guns when an outdated version of superstruct was installed previously and was not updaing due to pacakge-lock.json, even though package.json specifies 'latest'.
| "module": "./dist/index.js", | ||
| "types": "./dist/index.d.ts", | ||
| "exports": { | ||
| ".": { | ||
| "import": { | ||
| "types": "./dist/index.d.ts", | ||
| "default": "./dist/index.js" | ||
| }, |
There was a problem hiding this comment.
As discussed, this fix resolves the "Masquerading as ESM" issue that affected previous releases. This is demonstrated by the ATTW diagnostics results (before vs. after).
In the current JavaScript ecosystem, as long as "type": "module" is specified in package.json, there is no distinction between .js vs. .mjs and .d.ts vs. .d.mts files, so this should work without issue.
That said, all else being equal, I wonder if preferring explicit file extensions (exclusively using .mjs, .d.mts for ESM) would help future-proof the code against any potential breaking changes in the module system implementations of ECMAScript, Node.js, or TypeScript. Given the complicated, ongoing history of CJS/ESM-interop this doesn't seem like a remote possibility.
I'm curious whether you see any advantage in using the ambiguous .js, .d.ts extensions, or if you are indifferent between the two options?
2 participants
No description provided.