Conversation
| ".": { | ||
| "types": "./index.d.ts", | ||
| "module-sync": "./lib/index.mjs", | ||
| "require": "./lib/index.js", | ||
| "default": "./lib/index.mjs" | ||
| } |
There was a problem hiding this comment.
I think this should be
| ".": { | |
| "types": "./index.d.ts", | |
| "module-sync": "./lib/index.mjs", | |
| "require": "./lib/index.js", | |
| "default": "./lib/index.mjs" | |
| } | |
| ".": { | |
| "types": "./index.d.ts", | |
| "module-sync": "./lib/index.mjs", | |
| "import": "./lib/index.mjs", | |
| "require": "./lib/index.js" | |
| }, | |
| "./package.json": "./package.json" |
right? the default fallthrough is to remain CJS, not ESM. Anything that require()s and understands exports will hit require. If it supports require(esm) then it stops at module-sync. Anything that can import will be directed to ESM
Also adding an exports map is breaking on its own.
There was a problem hiding this comment.
Using import/require vs require/default I think is equivalent, so I don't have a preference for one vs the other
I don't think you really need to export package.json. There was an old version of rollup-plugin-svelte that required it, but otherwise I don't think there's a great reason to do it
Ah, yeah, I guess adding an exports map could be breaking if someone were trying to access something that wasn't intended to be exposed. I forgot about that...
Leaving the
mainandmodulefor now for backwards compatibility. Those could potentially be dropped with the next major