Prebundling of libraries with Svelte components

[benmccann]

Describe the bug

See illright/attractions#311 (comment) for the original report

It was loading all of svelte-feather-icons when you use just a few icons. Vite is supposed to do dependency pre-bundling to avoid this: https://vitejs.dev/guide/dep-pre-bundling.html#the-why. However, Vite's pre-bundling uses esbuild, so we disabled it on Svelte components because it doesn't know what to do with .svelte files.

Evan has proposed changing this. I'm finally a convert to the idea.

Reproduction

Try to use svelte-feather-icons

Logs

https://github.com/illright/attractions/ was making 485 requests for each page in dev mode taking 10s to load

System Info

Vite 2.6.7

Severity

serious, but I can work around it

Additional Information

You can work around it by doing deep imports

[antony]

This was the same in Sapper. Reloads were taking 60 seconds. I made a reduced version of the library including only the icons we required, and reloads started taking 20 seconds. Game changer.

I suppose what this means is that, the library isn't properly tree-shakeable.

[benmccann]

I don't think there's anything we can change in the library or is related to tree shaking, but requires changes in Vite. I updated the description with more details

[dominikg]

Until vite can pre-bundle svelte libraries it's best to use deep imports to avoid paying the tax of loading all exported svelte components.

Icon libraries are usually the worst in this context, luckily https://github.com/antfu/unplugin-icons does not suffer from this.

[techniq]

I've seen some discussion in carbon-components-svelte to preprocess the base imports to the individual full source Svelte code paths, which looks like it should help.

I've been meaning to try this approach myself for some libraries I've been working on but so far it hasn't been an issue enough to try. For icons I typically use @mdi/js for the icon paths and have a single Icon component to setup the SVG viewport/etc (ex. <Icon path={mdiSomething} />). Adding @mdi/js to optimizeDeps.include seems to make it performance tolerable so far.

[benmccann]

Wow, that's a great solution! Yeah, I wonder if we could tweak that library and use it generally. I've asked the author in carbon-design-system/carbon-preprocess-svelte#20

[dominikg]

@bluwy didn't we discuss something like that before? Main problem i see is that a generic preprocess-use-deep-import would have to resolve the intended target on the spot, following multiple reexports in the worst case

[bluwy]

I think we discussed something similar too about transforming the entrypoint with only the named imports, so it works more generically. The preprocessor technique is interesting though, I suppose it can be worked around by checking the exports field and naively work with that.

Anywho, I've been working today on actually prebundling Svelte libraries. It seems to be working on this branch. Wish I thought about it sooner 😄 The caveats now are that:

1. Prebundling would take a while (6s for carbon-components-svelte), but that's negligible in the long run.
2. Deeply importing Svelte components is not compatible, it could cause multiple instance of carbon-components-svelte running. Unless we force prebundle that nested import too. Could be a bug in Vite.
3. The generated sourcemap causes Vite to log "Unrestricted file system access". Could be an implementation error.

In that branch, I have a big-component-library playground to test out. I'd appreciate if anyone likes to test this in their project as well.

[benmccann]

I don't think the prebundling delay is too much of a big deal since it's only the first time you start the dev server and doesn't happen on subsequent runs.

Adding a link to the merged PR for the new feature for reference: sveltejs/vite-plugin-svelte#200

[bluwy]

Since 1.0.0-next.185, you can set experimental.prebundleSvelteLibraries: true in svelte.config.js to test out the new prebundling handling. Feedback appreciated!