Svelte components still don't always get styles when rendered conditionally

[Snugug]

Astro Info

Astro                    v6.1.0
Vite                     v7.3.1
Node                     v24.11.1
System                   macOS (arm64)
Package Manager          pnpm
Output                   static
Adapter                  none
Integrations             @astrojs/svelte (v8.0.3)
                         nebula-cms (Local)

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

This is a continuation of #14252. In NebulaCMS, I'm conditionally loading the actual editor form (https://github.com/Snugug/nebula-cms/blob/main/src/client/Admin.svelte#L233-L238) from a client:load component. In development, all of the CSS appears to load fine, but in production, the CSS for MetadataForm doesn't load and there's no errors in the console.

If helpful, I tried tracing this with an LLM, and the LLM suggests that this is the flow that's the problem:

1. @sveltejs/vite-plugin-svelte sets cssScopeTo metadata on Svelte CSS virtual
2. In the SSR build, Rollup tree-shakes conditionally-rendered components (behind {#if} blocks that don't execute during prerendering). Vite's CSS tree-shaking uses cssScopeTo to also remove their CSS from the SSR output
3. But Astro's cssModuleToChunkIdMap still maps all CSS module IDs from the SSR chunk (they're present as modules, just content-empty)
4. In the client build, allCssInSSR evaluates to true (all IDs mapped), so cssBuildPlugin deletes the client CSS asset from the bundle
5. The cssScopeTo fix from PR Include styles for conditionally rendered Svelte 5 components #15227 adds the deleted CSS filename to pagesToCss, but inlineStylesheetsPlugin iterates Object.entries(bundle) — the asset was already deleted, so it's never processed
6. Result: only SSR-rendered component styles make it to the final output

The LLM's suggested fix (internal t my project) is to override cssscopeTo via Vite plugin, which does appear to work, so it looks like it is at least related to that.

What's the expected result?

Svelte components that are rendered from NPM models, even if they're conditionally included in the code, should have their CSS available in a production build

Link to Minimal Reproducible Example

https://github.com/Snugug/nebula-cms/releases/tag/v0.1.5

Participation

• I am willing to submit a pull request for this issue.

[Snugug]

I'm unfortunately not comfortable enough with the inner works of Vite and Astro to fully debug and write a PR for this, but I'd be willing to take a swing at it with LLM assistance if someone who is more knowledgable is up for confirming that this appears to be the right path reviewing the work (I will make sure I understand what I submit before submitting it, to the best of my ability, it won't just be vibe coded schlock).

[matthewp]

Astrobot, please try again with the latest code.

[astrobot-houston]

• Reproduced: Yes
• Exploration: Yes — View branch
• Unit Test: Yes — updated existing packages/integrations/svelte/test/fixtures/conditional-rendering/src/components/Parent.svelte to deterministically reproduce the bug (changed Math.random() > 0.5 to $state(false))
• Priority: P4: important. This silently drops CSS for any Svelte component rendered behind an {#if} block that is false during SSR — a common pattern when state is set after mount or user interaction. It affects all Astro + Svelte users with conditionally rendered components in production builds, with no errors or warnings.

The root cause is a timing issue in packages/astro/src/core/build/plugins/plugin-css.ts. During the client build, the CSS deduplication logic deletes the client CSS asset (which contains styles for all components, including conditionally rendered ones) because allCssInSSR evaluates to true — all CSS module IDs exist in the SSR map. However, the SSR build's CSS is incomplete because Vite's cssScopeTo feature tree-shook the CSS for components not rendered during SSR. The existing cssScopeTo recovery code (from PR #15227) correctly identifies the missing CSS but runs after the asset has already been deleted from the bundle, so the inlineStylesheetsPlugin never finds it.

I found a potential fix for this issue. The fix saves CSS assets to a temporary map before deleting them during the client build's deduplication pass. After the cssScopeTo recovery code completes its CSS-to-page mapping, any deleted assets that are now referenced are restored to the bundle. The existing test fixture was also updated to use $state(false) instead of Math.random() > 0.5, which was only passing by coincidence (~50% of the time the component rendered during SSR, masking the bug).

Try this fix

You can test this fix right now without waiting for a release:

npm i https://pkg.pr.new/astro@61f2a77
npm i https://pkg.pr.new/@astrojs/svelte@61f2a77

If this fixes your issue, please leave a comment letting us know (e.g. "confirmed, this fixes it"). We'll then open a pull request to get this merged.

Full Triage Report

Triage Report: Issue #16251 — Svelte components still don't always get styles when rendered conditionally

Issue Summary

Title: Svelte components still don't always get styles when rendered conditionally
URL: #16251
Author: @Snugug
Labels: needs triage
Created: 2026-04-07

Description

This is a continuation of issue #14252. When Svelte components are conditionally rendered using {#if} blocks in a client:load component, the CSS for those conditionally-rendered components is missing in production builds. Development mode works fine.

Expected Behavior

Svelte components that are conditionally rendered (behind {#if} blocks) should still have their CSS available in production builds.

Actual Behavior

CSS for conditionally-rendered Svelte components is completely missing from the production build output. No errors are shown.

Environment

• Astro v6.3.3 (latest from monorepo), also reproduced on reporter's v6.1.0
• @astrojs/svelte v8.1.1 (latest from monorepo)
• Node v24.15.0

Reproduction

Status: ✅ REPRODUCED with a minimal setup:

1. Create an Astro project with @astrojs/svelte
2. Create a parent Svelte component with client:load that conditionally renders a child behind {#if showConditional} where showConditional = $state(false) (set to true in $effect())
3. Run astro build
4. The child component's CSS is missing from dist/index.html

Baseline verified: removing the {#if} block makes the CSS appear correctly.

Root Cause

Confidence: HIGH

The bug is in packages/astro/src/core/build/plugins/plugin-css.ts, in the cssBuildPlugin's generateBundle method — a timing/ordering issue:

1. SSR build maps all CSS module IDs to cssModuleToChunkIdMap, even though cssScopeTo tree-shook the conditional component's CSS content to empty
2. Client build — deletion checks allCssInSSR (true, because IDs exist) and deletes the client CSS asset (which has the full styles including the conditional component)
3. Client build — cssScopeTo recovery correctly identifies the CSS is needed and adds it to pagesToCss, but the asset was already deleted
4. inlineStylesheetsPlugin iterates Object.entries(bundle) and can't find the deleted asset

Additionally, the existing test from PR #15227 uses Math.random() > 0.5 as the condition, making it pass ~50% of the time by coincidence rather than testing the actual bug scenario.

Fix

The fix saves CSS assets to a deletedCssAssets map before deletion. After all CSS-to-page mapping (including cssScopeTo recovery) completes, any deleted assets now referenced in pagesToCss or moduleIdToPropagatedCss are restored to the bundle. The test fixture was updated to use $state(false) for deterministic reproduction.

Verification

• ✅ ConditionalChild CSS now appears in production build output
• ✅ All 33 Svelte integration tests pass
• ✅ All core CSS tests pass (css-assets, css-deduplication, css-inline-stylesheets, css-order, etc.)

Git diff

diff --git a/packages/astro/src/core/build/plugins/plugin-css.ts b/packages/astro/src/core/build/plugins/plugin-css.ts
index 2a833c1209..5dc603801f 100644
--- a/packages/astro/src/core/build/plugins/plugin-css.ts
+++ b/packages/astro/src/core/build/plugins/plugin-css.ts
@@ -92,6 +92,11 @@ function rollupPluginAstroBuildCSS(options: PluginOptions): VitePlugin[] {
 			const componentToPages = new Map<string, Set<string>>();
 
+			// Track CSS assets deleted during the client build so they can be restored
+			// if the cssScopeTo recovery code determines they're needed for conditionally
+			// rendered components whose CSS was tree-shaken during SSR.
+			const deletedCssAssets = new Map<string, (typeof bundle)[string]>();
+
 			if (this.environment?.name === ASTRO_VITE_ENVIRONMENT_NAMES.client) {
@@ -126,8 +131,14 @@ function rollupPluginAstroBuildCSS(options: PluginOptions): VitePlugin[] {
 
 						if (allCssInSSR && shouldDeleteCSSChunk(allModules, internals)) {
-							// Delete the CSS assets that were imported by this chunk
+							// Delete the CSS assets that were imported by this chunk,
+							// but save them first so they can be restored if cssScopeTo
+							// recovery needs them.
 							for (const cssId of meta.importedCss) {
+								if (bundle[cssId]) {
+									deletedCssAssets.set(cssId, bundle[cssId]);
+								}
 								delete bundle[cssId];
 							}
@@ -268,6 +279,29 @@ function rollupPluginAstroBuildCSS(options: PluginOptions): VitePlugin[] {
 			}
+
+			// Restore deleted CSS assets that are now referenced in pagesToCss or
+			// moduleIdToPropagatedCss.
+			if (deletedCssAssets.size > 0) {
+				for (const pageModuleSpecifier in pagesToCss) {
+					for (const cssId in pagesToCss[pageModuleSpecifier]) {
+						if (deletedCssAssets.has(cssId) && !bundle[cssId]) {
+							bundle[cssId] = deletedCssAssets.get(cssId)!;
+							deletedCssAssets.delete(cssId);
+						}
+					}
+				}
+				for (const moduleId in moduleIdToPropagatedCss) {
+					for (const cssId of moduleIdToPropagatedCss[moduleId]) {
+						if (deletedCssAssets.has(cssId) && !bundle[cssId]) {
+							bundle[cssId] = deletedCssAssets.get(cssId)!;
+							deletedCssAssets.delete(cssId);
+						}
+					}
+				}
+			}

Test fixture updated from Math.random() > 0.5 to $state(false) with $effect(() => { showChild = true }).

This report was made by an LLM. The analysis may be wrong, and the potential fix might not work, but is intended as a starting point for exploring the issue.

[matthewp]

Astrobot, I can confirm this fixes the issue.

[astrobot-houston]

The fix has been verified! A pull request has been created: #16823