feat: use @vitejs/plugin-rsc

[hi-ogawa]

(EDIT: see also blog post for the summary #1564)

This PR replaces Waku's vite and react-server-dom-webpack internals with @vitejs/plugin-rsc.

The new code path is split in waku/src/vite-rsc/... but Waku's core routing logic is reused internally. Previously implementation is still preserved and can be enabled via a flag --experimental-legacy-cli e.g.

pnpm -C examples/01_template dev --experimental-legacy-cli

The goal is to achieve the switch with as little breaking change as possible. There are still missing pieces as I wrote in todo at the bottom, but the overall shape is mostly established, so I'm opening a PR here to start to gather feedback. Thanks!

known changes

• new { vite: ... } config in waku.config.ts
  • this replaces custom vite.config.ts and unstable_viteConfigs in waku.config.ts
  • custom plugin can access environment API configuration and plugin system
    • https://vite.dev/guide/api-environment.html
    • https://vite.dev/guide/api-environment-plugins.html

// waku.config.ts
import { defineConfig } from "waku/config"

export default defineConfig({
  vite: {
    plugins: [ ... ],
    environments: {
      client: { ... },
      ssr: { ... },
      rsc: { ... },
    }
  }
})

• ssr environment (previously "main server ssr") doesn't externalize server deps by default, but transform all react deps.
  • This means if there's cjs dependency (directly or transitively) used in client component, SSR might fail during dev. For example, swr (esm) package uses use-sync-external-store (cjs) internally. This can be mitigated by environments.ssr.optimizeDeps.include: ["swr"].
  • See also Improve optimizeDeps.include heuristics to ensure popular cjs packages to be automatically optimized vitejs/vite-plugin-react#610

e2e status

Run it locally e.g. by

TEST_VITE_RSC=1 pnpm exec playwright test --project=chromium-dev e2e/rsc-basic.spec.ts
pnpm -C e2e/fixtures/rsc-basic dev --experimental-vite-rsc

• broken-links
• create-pages
• define-router
• fs-router
• hot-reload
• monorepo
• multi-platform
• partial-build
• render-type
• rsc-asset
• rsc-basic
• rsc-css-modules
• ssg-performance
• ssg-wildcard
• ssr-basic
• ssr-catch-error
• ssr-context-provider
• ssr-redirect
• ssr-swr
• ssr-target-bundle
• use-router
• examples-smoke
  • 11_fs-router (build)
  • 12_nossr (build)
  • 36_form (see test: React.use server promise on client #1534)
  • 38_cookies (build)
  • website

todo

• test: waitForHydration or not? feat: use @vitejs/plugin-rsc #1493 (comment)
• reduce diff
• announcement docs: add blog post for @vitejs/plugin-rsc migration #1564
• discuss dependency structure (dep vs peer-dep, @hiogawa/vite-plugin or wait for it to move to vitejs org)
• replace completely feat: remove --experimental-legacy-cli and legacy implementation hi-ogawa/waku#20
• test: fix windows ci fail test: full ci hi-ogawa/waku#11
• deployment adapter feat: deployment adapters hi-ogawa/waku#8
  • vercel example https://waku-vite-rsc-01-template.vercel.app
• "use client" transform with allowServer feat(rsc, transforms): support preserving client reference original value hi-ogawa/vite-plugins#1078
• improve waku.config support feat: support waku.config hi-ogawa/waku#5
• polish middleware refactor: align middleware system hi-ogawa/waku#7
• integrate hono feat: support hono enhancer hi-ogawa/waku#6
• check if any known issues will be fixed by this change. (if it's still not working, check if it's also reproduce with https://github.com/hi-ogawa/vite-plugins/tree/main/packages/rsc and raise it as an upstream issue)

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Skipped Deployment

Name	Status	Preview	Updated (UTC)
waku	⬜️ Ignored (Inspect)	Visit Preview	Aug 2, 2025 6:10am

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[dai-shi]

Cool. Very nice work. So excited to see this will land once it's finished.
This PR includes some improvements that can be applied already.
Here's our strategy:

• Split changes that are mergable to main, and merge them in advance
• Create changes that help reduce diffs, and merge them in advance
• Remove the experimental flag

Really our goal is gradually add changes as much as possible and make the final PR as minimal as possible.

[dai-shi]

some minor notes

[dai-shi]

I'll continue reviewing and refactoring after merging too.

[himself65]

congrats!

[hi-ogawa]

Thank you!