fix #230 : CJS / ESM conflict

[tipy01]

Before submitting the PR, please make sure you do the following

• It's really useful if your PR relates to an outstanding issue, so please reference it in your PR, or create an explanatory one for discussion. In many cases features are absent for a reason.
• This message body should clearly illustrate what problems it solves. If there are related issues, remember to reference them.
• Ideally, include a test that fails without this PR but passes with it. PRs will only be merged once they pass CI. (Remember to npm run lint!)

Tests

• Run the tests tests with npm test or yarn test

[kaisermann]

Hey @tipy01 👋 thanks for the PR. However, this has to be done carefully (see https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons), so I'll get to this when possible

[tipy01]

In last forced commit I:

• rebased to main
• use of .mjs and .cjs extension instead of .esm.js and .cjs.js (doing such change make my both Svelte3/ts-nodeCjs and Svelte4/ts-nodeEsm projects unit tests and build working properly, better compared with my Allow unit tests with ts-node esm #219 issue comment).
• upgraded the intl-messageformat from 9.13.0 to 10.5.3 to target the CJS / ESM conflict #230 issue

But I do not use SvelteKit so I guess someone else should test that on a SvelteKit based project.

[benmccann]

This looks good to me. I've dealt with the CJS/ESM stuff a ton, so am pretty confident in this PR. I'll note that introducing exports is encouraged but is also technically a breaking change at it stops people from being able to access non-exported files. So it's probably good practice to bump the major version when merging this PR. And if you're doing that, I'd recommend also dropping the CJS version at the same time

[kaisermann]

@tipy01 thanks for the update! I will get to test this this weekend and hopefully merge it soon. Following what @benmccann suggested, I think having the exports is the correct way forward too.

I'm gonna check if bumping the intl-messageformat is enough to fix it for the current major. If it is, I will release a version with only that. Then I will release the new major with the rest of the changes.

[tipy01]

I'm gonna check if bumping the intl-messageformat is enough to fix it ...

I found a stackoverflow thread about that.

[benmccann]

I'd personally make it just:

Suggested change

	"import": "./dist/runtime.js",
	"require": "./dist/runtime.cjs"
	"default": "./dist/runtime.js"

[tipy01]

Yes and it would work also just adding the "default": "./dist/runtime.js" line because it is just a fallback. All this stuff is documented here.

I personally do not need of cjs so I do not care on if this package is a "Dual CommonJS/ES module package" or just esm.

@kaisermann will split this PR and then he will decide on keeping or not the cjs.

[kaisermann]

I think we can be esm-only from v4 onwards, assuming 3.7.5 will be working as expected.

[kaisermann]

Gonna merge this onto the v4 branch and work from there 🙏 thanks for all the help

#238