Description

SvelteKit needs to add Svelte libraries to noExternal to compile the .svelte files. We'd also like devDependencies to be bundled and dependencies not to be. This is because when people run npm install in production they're not getting their devDependencies installed, so it'd be nice to bundle those.

This is almost impossible because we can't just add the devDependencies to noExternal since it doesn't also add the transitive dependencies.

We can't set noExternal to true and add the dependencies to external because external takes precedence making it easy for a user to add a Svelte library to dependencies/external which would cause it to break since Svelte needs to be bundled (proposed in sveltejs/kit#6301). If you do the reverse and add devDependencies to noExternal it still allows vite-plugin-svelte to add things to noExternal without harsh overrides

It also turns out that noExternal: true is basically impossible to use because it validates that you don't import any Node built-ins, which is maybe useful for deploying to a target like Cloudflare workers, but quite often is a frustrating restriction. (Edit: turns out you can work around that sveltejs/kit#6301 (comment))

Suggested solution

The ssr.external and ssr.noExternal docs are fairly vague. If my recollection serves me, one deals with libraries and one with .js files. It would be nice to clarify what they operate on

Given my current lack of clarity as to how these options work, it's hard for me to suggest solutions. Is it possible for the options to take effect not just for the individual libraries, but also their dependencies?

Alternative

This is currently being worked around by bundling the Vite output with esbuild, but that seems like it should be unnecessary. The second bundling step adds an additional layer of complexity and causes users to hit all of esbuild's bugs (e.g. sveltejs/kit#6440)

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.