[fullstack] Add experimental CSS deduplication between server and client builds

[Copilot]

• Understand the current CSS processing flow in both SSR and client builds
• Track CSS files generated during SSR build
• During client build, detect when CSS was already processed in SSR build
• Return empty CSS content for duplicated CSS files in client build
• Ensure CSS is properly deduplicated in final output
• Test that CSS still works correctly after deduplication
• Add configuration option to enable/disable the feature (opt-in/out)
• Document the feature in README
• Address code review feedback
• Verify backward compatibility
• Mutate client chunk metadata to reference SSR CSS files
• Inline cssDeduplicationPlugin inside assetsPlugin
• Fix type error for chunk.viteMetadata.importedCss

Changes

Addressed feedback to:

1. Inline cssDeduplicationPlugin directly inside assetsPlugin array
2. Fix type error by using type assertion: (chunk.viteMetadata as { importedCss: Set<string> }).importedCss = newImportedCss
3. Verified linting, build, and tests pass

The functionality remains the same - CSS deduplication works correctly and the manifest includes both CSS files as expected.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[fullstack] deduplicate client and server css on build</issue_title>
<issue_description>Currently css imported by universal module are processed by both builds. Css from server build is copied to client build.

Ideally, css imported on server module graph can be intercepted and move it as client build entry (similar to current dynamic client entry or rsc client reference). In this way, css processing and code splitting is centralized on client build and it would be probably more predictable.

To be investigated

• How about css module? Might need to track it back class names between two builds?
• How about build-time css framework (e.g. vanilla-extract)? it might need processing to happen where it's imported as it works based on code usage.

Either way, it's worth exploring this approach and add an ability to enable it as opt-in/out.</issue_description>

Comments on the Issue (you are @copilot in this section)

@hi-ogawa A different idea is: - after ssr build, we know which css file is ssr build. - during client build, can we forcefully emptify css when the same css is already included in ssr build @hi-ogawa @copilot try https://github.com//issues/1244#issuecomment-3419570736

Fixes #1244

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[hi-ogawa]

@copilot
Though we want to "remove" duplicate css build, we still want client build logic to be aware of equivalent css dependency from server build css. Can we somehow mutate chunk.viteMetadata.importedCss on client build to directly reference the one on server?

[Copilot]

@copilot
Though we want to "remove" duplicate css build, we still want client build logic to be aware of equivalent css dependency from server build css. Can we somehow mutate `chunk.viteMetadata.im...

Done! Modified the implementation to mutate chunk.viteMetadata.importedCss on client chunks to reference the SSR CSS files.

The client entry now includes both CSS files in the manifest:

• /assets/entry-tn0RQdqM.css (empty, deduplicated)
• /assets/index-H-tL5qL1.css (full CSS from SSR)

This ensures the client build is aware of the CSS dependencies from the server build. (commit: will be in next message after push completes)

@copilot
Though we want to "remove" duplicate css build, we still want client build logic to be aware of equivalent css dependency from server build css. Can we somehow mutate `chunk.viteMetadata.im...

Done in commit c4c7b01! Modified the implementation to mutate chunk.viteMetadata.importedCss on client chunks to reference the SSR CSS files.

The client entry now includes both CSS files in the manifest:

• /assets/entry-tn0RQdqM.css (empty, deduplicated)
• /assets/index-H-tL5qL1.css (full CSS from SSR)

This ensures the client build is aware of the CSS dependencies from the server build.

[hi-ogawa]

@copilot do following

• inline cssDeduplicationPlugin inside assetsPlugin
• fix type error chunk.viteMetadata.importedCss = [...newImportedCss];
• ensure ci passes

[Copilot]

@copilot do following

• inline cssDeduplicationPlugin inside assetsPlugin
• fix type error chunk.viteMetadata.importedCss = [...newImportedCss];...

Done in this commit:

1. ✅ Inlined cssDeduplicationPlugin inside assetsPlugin
2. ✅ Fixed type error using type assertion: (chunk.viteMetadata as { importedCss: Set<string> }).importedCss = newImportedCss
3. ✅ CI checks pass (linting, build, tsc, basic example build)

Manifest still correctly includes both CSS files as expected.