[vite-plugin-svelte] prebundle libraries / ssr compile stats show large numbers

[dominikg]

This is not a bug in carbon-components-svelte, posting here for visibility and as a heads-up for the maintainers and users.

In version 1.3.0 , vite-plugin-svelte is going to enable prebundling for svelte dependencies during dev by default.
Alongside, it is going to log compile statistics so users can understand where time is spent.

For a sveltekit application with carbon-components-svelte and carbon-icons-svelte this can look like

1:54:40 PM [vite-plugin-svelte] prebundle libraries in progress ...
1:54:55 PM [vite-plugin-svelte] ssr compile in progress ...
1:55:05 PM [vite-plugin-svelte] prebundle libraries done.
package                         files     time     avg
carbon-icons-svelte              2002   11.30s   5.6ms
carbon-components-svelte          206    2.68s  13.0ms
1:55:05 PM [vite-plugin-svelte] ssr compile done.
package                                 files    time     avg
carbon-icons-svelte                      2002   2.92s   1.5ms
carbon-components-svelte                  206   0.60s   2.9ms
playground-big-component-library-kit        3   9.8ms   3.3ms

and delay initial page load of the dev-server by multiple seconds.

Using the optimizeImports preprocessor in combination with prebundling can make it a lot worse even.

For using carbon with vite-plugin-svelte 1.3+ it is recommended to either not use optimizeImports and stick to one import style or exclude carbon from optimizeDeps as described in the vite-plugin-svelte FAQ

[benmccann]

It may be worth thinking about how carbon-icons-svelte is setup. I've been using svelte-awesome for icons and it is very fast as it only has ~5 .svelte files. That could possibly be a better approach than generating lots of .svelte files

[dominikg]

carbon icons are also available via unplugin-icons, so if you can build a config for that that works out to a similar interface as the current carbon-icons-svelte package, carbon-icons-svelte would no longer be needed as a separate package and instead users projects would only compile/bundle the icons they actually use. Kind of like deep imports without the extra package.

// vite.config.js
import { defineConfig } from 'vite'
import { svelte } from '@sveltejs/vite-plugin-svelte' // or sveltekit
import Icons from 'unplugin-icons/vite'

export default defineConfig({
  plugins: [
    svelte(), // or sveltekit
    Icons({
      compiler: 'svelte',
      // TODO: add extra config here so compiled icon is similar to what carbon-icons-svelte has now
    }),
  ],
})

<script>
import IconAccessibility from '~icons/carbon/accessibility'
</script>
<IconAccessibility/>

[benmccann]

I'm not a big fan of the unplugin-icons approach as I'm not sure enterprise environments would let you download things on demand in their CI environments

[dominikg]

I'm not a big fan of the unplugin-icons approach as I'm not sure enterprise environments would let you download things on demand in their CI environments

you don't. you add a dependency on an iconify library, basically a json file with all svgs. it's just a bit clever glue to turn that json into a svelte component on demand

[theetrain]

I ran some somewhat-scientific tests and here is what I've uncovered:

• carbon-components-svelte runs very slow with vite dev whenever SCSS is involved
• using plain CSS, even the gigantic all.css (without using purgeCSS) is much more performant

This is concerning since Carbon v11's de facto styles involve SCSS exclusively. I haven't measured Carbon v11 React, so I'm unsure how things perform there.

Below are my test results. There were some inconsistencies:

• After the 1m38s reloads, HMR wouldn't work until I refreshed the page for another 1m38s, which is why some HMR results are very long

Test project: https://stackblitz.com/edit/sveltejs-kit-template-default-upbce6?file=src%2Fapp.scss,src%2Froutes%2F%2Bpage.svelte

On Stackblitz

Test Run	Using SCSS	Using CSS	Index imports	Deep import	vite .optimizeDeps .exclude	Reported time by vite-plugin-svelte	Actual render time	First HMR	Second HMR
1	Yes	No	Yes	No	Yes	1.58s	1m48s
2	Yes	No	Yes	No	No	1.39s	1m44s	3m11s	< 1s

Locally on 2015 Macbook Pro, on battery

Test Run	Using SCSS	Using CSS	Index imports	Deep import	vite .optimizeDeps .exclude	Reported time by vite-plugin-svelte	Actual render time	First HMR	Second HMR
1	Yes	No	Yes	No	No	1.39s	1m36s	1m10s	< 1s
2	Yes	No	Yes	No	Yes	1.46s	1m29s	1m8s	< 1s
3	Yes	No	No	Yes	No	0.16s	1m38s	2m37s	1m17s
4	Yes	No	No	Yes	Yes	0.17s	1m34s	30s	< 1s
5	No	No	Yes	No	No	1.17s	14s	30s	< 1s
6 🎉	No	Yes	Yes	No	No	1.49s	5s	<1 s	< 1s

Is there a way for us to improve performance when SCSS is involved? Perhaps there's a more efficient usage of SCSS that I've overlooked in the test project linked above.

[benmccann]

@theetrain would it be possible for you to preprocess the library and distribute just CSS? That's what we typically recommend svelte libraries to do and I believe if you use svelte-kit package it will do it for you. Then you can still author components with SCSS, but users won't need to incur the cost of processing it