Plugin waveform integration shows large bundle size

[ecstrema]

On build, I get this:

.svelte-kit/output/client/_app/version.json                                                 0.03 kB │ gzip:   0.05 kB     
.svelte-kit/output/client/.vite/manifest.json                                               5.53 kB │ gzip:   0.81 kB     
.svelte-kit/output/client/_app/immutable/assets/App.CCahpbvf.css                            0.04 kB │ gzip:   0.06 kB     
.svelte-kit/output/client/_app/immutable/assets/4.BDLXB7HW.css                              0.13 kB │ gzip:   0.13 kB     
.svelte-kit/output/client/_app/immutable/assets/3.CAMqKQym.css                              0.13 kB │ gzip:   0.13 kB     

[... ~20 other entries below 5kB]

.svelte-kit/output/client/_app/immutable/chunks/scheduler.BDbv0bUs.js                       7.34 kB │ gzip:   3.01 kB     
.svelte-kit/output/client/_app/immutable/entry/start.B0_Jn7u1.js                           28.00 kB │ gzip:  11.21 kB     
.svelte-kit/output/client/_app/immutable/chunks/App.BQfPGA7d.js                           156.51 kB │ gzip:  47.69 kB     
.svelte-kit/output/client/_app/immutable/chunks/tweakpane-plugin-waveform.CqpbEbFB.js   1,851.88 kB │ gzip: 427.60 kB

(!) Some chunks are larger than 500 kB after minification. Consider:
- Using dynamic import() to code-split the application
- Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/configuration-options/#output-manualchunks
- Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.

Notice the warning at the end, and the size of the last chunk.

Since I'm not even using the waveform plugin, and most of my other chunks are under 8kB, I'm really wondering what's happening there. Why is tree shaking not working for the waveform plugin? I don't even know if the error is from tweakpane itself or your otherwise fantastic library here.

Do you know what could be causing that?

[kitschpatrol]

Hi, thanks for trying out the library and for bringing up this concern.

You're right that tree shaking seems to miss a lot of unused branches. I dug into this a bit during development without finding a satisfactory fix, and the current workaround is to use default imports instead of named imports, targeting only the components you need, as described here: https://kitschpatrol.com/svelte-tweakpane-ui/docs#importing-components

Let me know if that gets your bundle size down, and I'm open to any insights into how I could structure the library to encourage the tree shaker to work more aggressively when using named imports instead of default imports.

[ecstrema]

Effectively, using default imports reduced noticeably the last chunks. It's still far from perfect, and tree shaking really is something hard to debug, so it'll stay that way for now.

Thank you for checking!

[kitschpatrol]

Glad that helped, but the build sizes still bug me so I looked into this a bit further, and picked up a few new insights:

• The bloat doesn't seem specific to tweakpane-plugin-waveform, for some reason code for multiple plugins is ending up in that chunk. If you remove tweakpane-plugin-waveform from the library entirely, then you still end up with a bloated chunk containing code for multiple plugins.
• There's a bunch of duplicated code in the built files, which looks like it's from @tweakpane/core
• The rollup configuration in Tweakpane plugin template, which is the project boilerplate most the third-party plugin use, does not seem to externalize @tweakpane/core as a production dependency. Instead, it gets bundled into the single-file plugin artifact, which is what's published to NPM and imported by plugin consumers. Since the duplicative @tweakpane/core code ends up embedded in the same file as the plugin-specific code, it cannot be deduplicated by vite.
• In a quick test in one of the third-party plugin projects, externalizing the @tweakpane/core dependency saves about 110k in the minified plugin artifact.
• There are seven third party plugins included with Svelte Tweakpane UI, so that's perhaps ~770k of duplicative @tweakpane/core code.

So, I think we're seeing the tradeoffs between distributing plugins as built artifacts instead of source, which is the Tweakpane project's chosen approach. This has some advantages for ease of distribution, but eliminates some opportunities for subsequent build optimization. (FWIW Svelte does the opposite, distributing libraries as .svelte source files.)

I don't know of a solution for this other than maintaining a fork of each plugin with @tweakpane/core externalized in its build configuration, which would be a bit of work, unless there's a way to get the bundler to deduplicate the output.

Regardless of possible optimizations in how the third-party plugins are built, it's worth noting that using default instead of named imports still matters for tree shaking / dead code elimination.

I will keep this issue open and plan to pursue the externalization strategy when time permits.

[kitschpatrol]

I just updated all the plugin dependencies to externalize @tweakpane/core, and it seems to work well.

With my test project that includes every component from the library, I saw the following changes in a production build:

	Sum of Chunks	Sum of Chunks (gzip)	Largest Chunk	Largest Chunk (gzip)
Before	1599 K	422 K	1014 K	215 K
After	819 K	260 K	233 K	53 K

Pretty close to the 770 K savings estimate. The largest chunk is about a quarter of its previous size, and well under the default 500 K chunk size warning threshold.

Again when bundle size is critical, it's still worth using default instead of named imports in addition to this optimization, since tree shaking is a separate issue.

Released in v1.2.6.

[kitschpatrol]

And (much) longer term, it looks like Svelte 5 might bring further relief:

Files & size

The project has a total of 232 files, whereby there are 147 Svelte components in real terms (not including tests and demos). The migration from v4 to v5 has reduced the size of files from 135kb to 126kb. The demo build file (JS) was with v4: 382kb - and with v5: 171kb (55% smaller)! But I think this will only be small if you use the new Runes mode.

I used the new strict runes mode and had to change 207 files (90%), which took 1 week. I didn't have to change a single line of CSS code.

Via a Reddit thread regarding a different project

[kitschpatrol]

Closing this since there should be significant improvement in bundle size after v1.2.6.

If that's not the case, feel free to comment and I'll re-open!