-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace custom Rollup setup with tsup #1268
base: main
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
No description provided.