🦋 Changeset detected

Latest commit: ee4869f

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Preview: https://svelte-dev-git-preview-svelte-15450-svelte.vercel.app/

Playground

pnpm add https://pkg.pr.new/svelte@15450

This feels very specific to vite-plugin-svelte, and given that zimmerframe is already in the dependency graph for anyone using it, the cost of doing the work inside vite-plugin-svelte feels very small, especially with the .includes(':global') check.

Given that, do we really want to add it here? It adds more code to svelte than vite-plugin-svelte would be able to remove, and the 'other tools' argument feels a bit hypothetical.

If the answer is 'yes' then I'd at least suggest changing the API so that it's result.css?.hasGlobal rather than adding metadata.

If the answer is 'yes' then I'd at least suggest changing the API so that it's result.css?.hasGlobal rather than adding metadata

Initially I added it there but it felt a bit wrong since we already have the metadata object. But if we want to move it it's fine too.

For the question of "should we do it" this could save one walk since we are already walking to analyze css but effectively does feels a bit specific.

At the end of the day the PR it's here, up to discuss if we want to do it, otherwise we can close it 😌

if this gets added in svelte itself i think the right place would be inside css. My motivation for putting it here was perf/logistics for the most part. svelte is writing css selectors without a scope class at some point so it must know already when output contains unscoped css and if its just a simple flip of a boolean it should be both less code and more performant. If it's the same song and dance as in vite-plugin-svelte with walking the ast again fine with me to keep it there.

Ultimately i hope we start to warn against using unscoped global styles in .svelte files. In my mind styles in <style> blocks of .svelte files should always come with some form of scoping to that component. independent styles should be defined in a separate file and imported as needed.

And if thats the case this PR could help to implement such a warning too.

Theoretically it is more efficient to do it here since it doesn't involve an additional walk, but we're talking about fractions of milliseconds for all but the largest <style> blocks (and in a tiny minority of components). So for me performance/efficiency doesn't really enter into the equation here — it's purely a question of whether the API belongs in the core. And that rests on whether things other than vite-plugin-svelte would realistically make use of it, which seems very doubtful to me (but if that was proven wrong we would always have the option of adding it in future). So my vote is to close this.