svelte-i18n: CJS / ESM conflict
From https://github.com/kaisermann/svelte-i18n/issues/209#issuecomment-1704354362
What I observed appears to have a different source. Somehow the modules are resolved the wrong way.
My application’s import resolves to node_modules/svelte-i18n/dist/runtime.cjs.js which has:
var IntlMessageFormat = require('intl-messageformat');
....
IntlMessageFormat.resolveLocale
...
new IntlMessageFormat(message, ...)
But the require('intl-messageformat') is resolved in such a way, that IntlMessageFormat is an object with a default property which contains the actual class, so the new IntlMessageFormat/IntlMessageFormat.resolveLocale errors. There probably is some mixing of CJS and ESM going on (this is always such a pain).
Unfortunately, I have not been able to create a minimal reproduction so far. This should probably be tracked in a separate issue.
The logged errors could maybe be more generic, as these are lies:
[svelte-i18n] The initial locale “de” is not a valid locale. [svelte-i18n] Message “…” has syntax error: IntlMessageFormat is not a constructor
_Originally posted by @brunnerh in https://github.com/kaisermann/svelte-i18n/issues/209#issuecomment-1704354362_
About this issue
- Original URL
- State: closed
- Created 10 months ago
- Comments: 22 (4 by maintainers)
Commits related to this issue
- downgrade svelte-i18n until this is fixed: https://github.com/kaisermann/svelte-i18n/issues/230 — committed to files-community/Website by TheOnlyTails 10 months ago
- fix #230 : CJS / ESM conflict — committed to tipy01/svelte-i18n by tipy01 9 months ago
- fix #230 : CJS / ESM conflict — committed to tipy01/svelte-i18n by tipy01 9 months ago
- fix: make package esm-only BREAKING CHANGE: package is now esm-only * chore(deps-dev): bump postcss from 8.4.29 to 8.4.31 Bumps [postcss](https://github.com/postcss/postcss) from 8.4.29 to 8.4.... — committed to kaisermann/svelte-i18n by tipy01 9 months ago
I’ve released
3.7.5-alpha.1with the updatedintl-messageformatversion. I’m gonna do a major bump soon with the appropriatepkg.exportsfield in thepackage.json, but just want to guarantee that the current major will be working in its final version.I’ve tested it with the repo made by @Pierstoval and the build is passing and the preview working
ESM runs on the server as well. All SvelteKit projects have been ESM-only since day 1. Svelte 4 only outputs ESM. Vite is dropping CJS support for the server in Vite 5 to be released shortly and 70% of Svelte users use Vite. CJS support in Svelte is basically dead at this point. If you still need it for some reason you can always import the library as ESM and then bundle your project to CJS.
I recommend using publint to diagnose issues like these: https://publint.dev/svelte-i18n@3.7.4
Also, given that this is a Svelte-specific library, there’s really no reason to have a CJS build. The best solution would be to drop the CJS version which would simplify things a fair amount
works with 3.7.3 for me, but not with 3.7.4
I spent hours looking at different versions of the package and the behavior made no sense to me at all.
After seeing in #232 that installing the latest version fixed this, I went through the various 10.x.x versions to see what change might have caused the fix and it started to work at v.10.1.2 which is a completely broken release that only contains the raw source. Later versions like v.10.1.3 appear to work as well, meanwhile the changelog is useless for those versions:
Changelog Snippet
Also, a locally installed v.10 should not even be used as far as I understand it, as the version specified by
svelte-i18nis^9.13.0which is not compatible with a major version change to version v.10.It’s been breaking either way; for me since 3.4.0. Though my issue might be less common since I am not using SvelteKit which is rather popular and a first-party framework.
You should be able to make Vite’s SSR work by adding this to the
vite.config.js:Context:
There are also options related to optimization that could be relevant; there is a note regarding ESM modules referencing CJS modules. (Tried a few things there, but it did not seem to matter.)
Rather annoying that this doesn’t “just work”. As noted, both packages in theory support both module types. I’d say the issue may be on the side of the build tooling here.
@oyvindo found another fix/workaround (#232):
Tested that and it seems to work, the reason is beyond me…
i’m using vercel-adapter and getting it
@kaisermann Works for me now.
3.7.4still has same issue@brunnerh I don’t have time right now to try to reproduce this, but I’m aware of this type of cjs/esm import conflict. Thankfully,
intl-messageformatalso exports the class as a named export. I just released version 3.7.4 which replaces the default import for the named ones. Can you tell me if it fixes the issue for you?