Automatically add svelte libraries to vite.optimizeDeps.exclude

[dominikg]

Describe the problem

dedupe does not work for optimized dependencies and this breaks stuff.

See
#124
vitejs/vite#3910
https://github.com/bluwy/vite-svelte-dedupe

Describe the proposed solution

To avoid this problem, automatically add svelte libraries to optimizeDeps.exclude.

Finding those libraries isn't bulletproof, the best you can do is check for the existance of a "svelte" field in it's package.json,

see https://github.com/sveltejs/kit/blob/69b92ec16ce92b86bc5a540daa8ddbd84ba400ef/packages/kit/src/core/utils.js#L85

Alternatives considered

keep the status quo and users have to apply it manually

Importance

would make my life easier

[mattjennings]

I like this. It's worth noting that svelte-kit package does not add a pkg.svelte property which is unfortunate, but it does add the .svelte files to pkg.exports. Maybe we could check those as well?

[dominikg]

it does? then it would also have to check that field in the code I linked 🤔
thanks for pointing it out.

also vite-plugin-svelte and other bundler plugins would also need to make sure to resolve via that custom ext.

[mattjennings]

That would explain why my libraries using kit package only work when under dependencies. Otherwise, they get that Must use import to load ES Module message unless it's added to vite.ssr.noExternal manually

For reference, here's the package.json: https://unpkg.com/svelte-modals@1.0.3/package.json.

[dominikg]

ah, it's only adding the path mapping, not a custom field. that's OK.

your problem is likely the incompatibility with esm-only packages in vite SSR.
vitejs/vite#4230 (comment)

[mattjennings]

Oh, yes, sorry, I meant to say we could skim through pkg.exports with .svelte extensions as an alternative to looking for pkg.svelte if it's not there. There is an issue being discussed for kit to add pkg.svelte, so maybe this is more of a kit issue anyway.

Thanks for the heads-up on the esm-only SSR bug though, that looks like the culprit.

[benmccann]

@btakita also reported that Vite optimization breaks Svelte in vitejs/vite#4306

But skipping optimization seems like a terribly painful solution because I believe it will also skip optimizing the transitive dependencies of the dependency you specify? Assuming that's right, it means that you cannot use any Svelte component with a non-ESM dependency, which would be a huge pain. And @GrygrFlzr suggested we can't simple re-include those transitive dependencies to be optimized vitejs/vite#3961 (comment)

I'm not in favor of short-term workarounds because it makes it harder to submit bug reports for the true underlying issues, etc. I've been having a hard time because many libraries I find hit multiple issues, which makes it hard to untangle things and come up with good test cases. I'm afraid this would just add an additional layer of complication. I've started creating a list of the various issues we need to solve: sveltejs/kit#2086

[benmccann]

I was thinking about this some more, dependency pre-bundling should only happen for non-ESM libraries and most Svelte components should be written in ESM. I wouldn't expect to hit this that often as a result. But could we instead try to detect Svelte components that aren't written in ESM and print a warning that the package source should be converted or that they should distribute an ESM version?

[dominikg]

Printing a warning is a good thing, asking users to start pestering library authors/maintainers to use a modern template like sveltekit package or follow it's "distribute as esm, include preprocessed .svelte" pattern

Unfortunately most older libraries are based on https://github.com/sveltejs/component-template or variants of it, so there are many different patterns out there.

As long as dedupe is only working for unoptimized dependencies, i think we should default to exluding all svelte libraries. If that excludes a cjs library that stops working as a result, the printed warning helps and users can still decide to manually reinclude it via optimizeDeps.include.
I prefer this over continued bug reports because failed deduplication, but happy to discuss this further :)

[benmccann]

sveltejs/component-template is also ESM, so there really shouldn't be many non-ESM Svelte components out there. I can't recall ever seeing a non-ESM Svelte component. I tried following the links to the various issue reports about this and the only instance I see is of someone manually adding a library to optimizeDeps.include. Perhaps we should just check that config value and print a warning if there are any Svelte components in there

[dominikg]

given this lib

  "name": "some-svelte-lib",
  "svelte": "src/index.js", // export { default as default } from './Component.svelte';
  "module": "dist/index.mjs", // esm  bundle via rollup, contains compiled svelte component
  "main": "dist/index.js", // UMD via rollup, contains compiled svelte component
  "type": "commonjs" // not actually in package.json, but missing type: module means commonjs by default

and this svelte component in a vite project

<script>
import Foo from 'some-svelte-lib'
</script>
<Foo/>

vites optimizer is going to auto optimize 'some-svelte-lib' unless told not to. The fact that main and svelte point to different things doesn't make it easier. and neither that depending on the project of the user main or module are going to be used.

I tried to have a look at the implementation of the optimizer but now my head hurts. its a mix of esbuild plugins and the plugincontainer resolver.