`adapter-cloudflare` seems to undo all code splitting, and worse

[tv42]

Describe the bug

I'm using cloudflare-adapter to deploy to Cloudflare Pages. My _worker.js is growing to ridiculous sizes, perhaps most relevantly, it's larger than my app with all its chunks!

$ du -sh --apparent-size .svelte-kit/output/ .svelte-kit/cloudflare/
1.2M	.svelte-kit/output/
3.4M	.svelte-kit/cloudflare/

My biggest dependency is mapboxgl, and I see it minified in .svelte-kit/cloudflare/**/_app/chunks/vendor-*.js. But, I also see it embedded in .svelte-kit/cloudflare/_worker.js. Why is it both split and not split?

Reproduction

TBD

Logs

$ npm run build
[ everything here is under 44 KiB ] 
.svelte-kit/output/client/compare/_app/chunks/vendor-6f46024b.js                                        901.61 KiB / gzip: 246.75 KiB

(!) Some chunks are larger than 500 KiB after minification. Consider:
- Using dynamic import() to code-split the application
- Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/guide/en/#outputmanualchunks
- Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.
vite v2.6.13 building SSR bundle for production...
✓ 77 modules transformed.
.svelte-kit/output/server/app.js   106.58 KiB

Run npm run preview to preview your production build locally.

> Using @sveltejs/adapter-cloudflare
  ✔ done

System Info

System:
    OS: Linux 5.14 NixOS 21.11 (Porcupine) 21.11 (Porcupine)
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
    Memory: 36.93 GB / 62.61 GB
    Container: Yes
    Shell: 5.1.8 - /nix/store/xdxv22yb7qnjfyf997r9fx804761z14c-bash-interactive-5.1-p8/bin/bash
  Binaries:
    Node: 16.13.0 - /nix/store/26lslfmvwyhspppbinznh111fyaxx62z-nodejs-16.13.0/bin/node
    npm: 8.1.0 - /nix/store/26lslfmvwyhspppbinznh111fyaxx62z-nodejs-16.13.0/bin/npm
  Browsers:
    Firefox: 94.0.2
  npmPackages:
    @sveltejs/adapter-cloudflare: ^1.0.0-next.2 => 1.0.0-next.2
    @sveltejs/kit: next => 1.0.0-next.191
    svelte: ^3.34.0 => 3.44.0

Severity

blocking an upgrade

Additional Information

This is severe because Cloudflare Workers _worker.js limit is only 1.5 MB, and importing mapboxgl without splitting uses a huge part of that.

[tv42]

So, this seems to be because of the esbuild.build({bundle: true}) call in the adapter.

If bundling everything into the single file is the desired behavior, why are the js files from .svelte-kit/output/client/compare/_app/chunks/ etc also copied into .svelte-kit/cloudflare? Now the content is there twice.

I cannot pass splitting: true to esbuild because that requires outdir which cannot be set at the same time as outfile and the adapter forces outfile.

Next up, trying to use dynamic imports.

[tv42]

Well, dynamic imports manage to split the dependency into its own .svelte-kit/output/client/**/_app/chunks/MyComponent-*.js, which is then promptly bundled back into _worker.js. :-(

[Rich-Harris]

This is how workers, well, work. _worker.js has to be a single file, it can't import from other modules (at least currently). Since MapboxGL happens to be the sort of library that doesn't really do anything outside the browser, what we really need is some way to specify that it shouldn't be included in the bundle. Not 100% sure what that looks like — it might work to dynamically import it inside an onMount, but if push comes to shove you can always just include it as a <script> tag in your app.html pointing to static/js/mapbox-gl.js and reference it as a global.

My biggest dependency is mapboxgl, and I see it minified in .svelte-kit/cloudflare/**/_app/chunks/vendor-*.js. But, I also see it embedded in .svelte-kit/cloudflare/_worker.js. Why is it both split and not split?

Everything in _app is a client-side asset, and your client-side assets are code-split.

[tv42]

My understanding is that Cloudflare Pages does not bundle all the static html, images, etc into _worker.js (I think I heard it uses KV, but haven't seen that confirmed). It would be neat for _worker.js to import from this store too, instead of bundling, for large chunks.

I was able to use a dynamic import with a wrapper component like this:

<script lang="ts">
	import { onMount, SvelteComponent } from 'svelte';

	let mapView: null | typeof SvelteComponent;

	onMount(async () => {
		const module = await import('$lib/map_view/MapView.svelte');
		mapView = module.default;
	});
</script>

<svelte:component this={mapView} {...$$props} />

However, it seems this gets tricky to generalize:

• you can't pass the import path as a prop, because then Vite says it can't analyze it, and the import fails
• you can't put the import in the caller as a <LazyComponent importer= {() => import('$lib/map_view/MapView.svelte')} /> or such, because that still causes the large dependency to be bundled.

[tv42]

For posterity, that seemed to run import() a every time a view was toggled between a list and a map, and I wasn't sure of the performance implications of that, so I added a cache:

<!-- Dynamic import MapView, and thus mapbox-gl, to keep Cloudflare Pages `_worker.js` size small. -->
<script context="module" lang="ts">
	import type { SvelteComponent } from 'svelte';

    // Cache the dynamic import, so it isn't re-run on every Map/List button toggle.
    let componentCache: typeof SvelteComponent | null = null;
</script>

<script lang="ts">
	import { onMount } from 'svelte';

    let mapView: typeof SvelteComponent | null = null;

	onMount(async () => {
        if (componentCache === null) {
			console.log('import');
			const module = await import('$lib/map_view/MapView.svelte');
			componentCache = module.default;
		}
        mapView = componentCache
	});
</script>

{#if mapView}
  <svelte:component this={mapView} {...$$props} />
{/if}

I wish this was easier to do without hardcoding the import in this wrapper (see earlier comment).

[syffs]

on the same topic of _worker.js size, is there a reason why it is not minified ?

In my case, it divides by 2 the worker size (~1.2MB => 600KB).

EDIT: it appears that cloudflare does its own minification/gzipping when publishing, which explains why some big raw worker still end up being OK with the 1MB worker size requirement.

[major-mayer]

I also stumbled across this problem.
When you upload the pre-built folder using Cloudflare's wrangler CLI, you don't even get an error message why the deployment has failed.
I had to put everything inside a Gitlab**.com** (you can't use your private Git instance) repo and do the build using Cloudflare's own GUI process, and then the error message came up:

Error: Failed to publish your Function. Got error: Your Functions script is over the 1 MiB size limit (workers.api.error.script_too_large

It took me a while to even find the error for this.

For me, the reason for my huuuge 6.4 MB _worker.js file was mainly the import of BabylonJS.
In addition, as @syffs said, the whole file is unminified, which wastes even more storage.

As a workaround, I changed the import of my BabylonJS wrapper class from this:

 import BabylonViewer from "./BabylonViewer";

to this:

onMount(async () => {
		let BabylonViewer = await import("./BabylonViewer");
		if (bjsCanvas) {
			let viewer = new BabylonViewer.default(bjsCanvas);
		}

	});

But there really should be a better way to specify which dependencies should belong into the _worker.js bundle.