fix: lib build-mode causes assets to be inlined (#461)

[aloker]

When running vite in lib mode, all assets referenced in css and js files are base64-inlined instead of being emitted as asset files.
Lib mode was apparently only enabled to avoid the warning wrt to the missing dynamic import module. However, in lib mode, the polyfill is not applied in the first place (https://vitejs.dev/config/#build-polyfilldynamicimport). So, dropping the lib mode and disabling the polyfill explicitly (polyfillDynamicImport: false) should work fine, too. Plus now assets get emitted properly (adhering to the assetsInlineLimit).

I did not find a way to test this automatically. Ideally a test would include a page that references e.g. an image by importing it and the test would check that a file is emitted. However, I could not find a way to test a post-vite build, so help is appreciated.

Tests and linting passed successfully. The example apps worked as they did before. The output of the non-lib-mode build is actually very similar to the lib-mode builds - as is expected.

I've created a changeset for this change.

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/sveltejs/kit/HyFCaQVF6CLrvD5ZiapnU7troBsy
✅ Preview: Canceled

[aloker]

So, the question that is left: is it actually desirable to have the dynamic import polyfill disabled? Note: it has been disabled so far anyway due to the lib mode build.

I've successfully build the examples in non-lib mode without setting polyfillDynamicImport: false by just adding 'import "vite/dynamic-import-polyfill"' to packages/kit/src/runtime/client/start.js. However, the default build config warns about the implicit external reference. So before investigating this further, I'd like to know whether supporting the polyfill is an actual goal.

[Rich-Harris]

Excellent sleuthing, thank you! I added a test and applied a similar change to the SSR build in 66ef622.

is it actually desirable to have the dynamic import polyfill disabled

It is, yes. SvelteKit apps use native import. In environments where that's not supported, we will fall back to something else (see #12); in either case, the dynamic import polyfill should be unnecessary