fix(rsc): serve app-router page modules in local dev under experimental.rsc (#3662)

[mattboon]

Bug

With experimental: { rsc: true }, veryfront dev returns 404 for every app-router client module (/_vf_modules/app/page.js, /_vf_modules/app/layout.js, /_vf_modules/app/<route>/page.js), the client throws Failed to fetch dynamically imported module, and nothing hydrates (it then also probes non-existent /_vf_modules/pages/*). Green on 0.1.1123, red on 0.1.1231, and specific to the experimental.rsc path — without the flag the same app-router routes hydrate fine.

Root cause (a regression from #3290)

#3290 introduced RSC-aware browser-module admission: browser-module-admission.ts sets requiresClientBoundary: rscEnabled && appRelative, and the bundler 404s an app-relative module with no use client directive. But it wired rscEnabled: isRSCEnabled(config) unconditionally (module-server.ts) — not scoped to hosted — and did not touch the hydration pipeline.

RSC client boundaries are a hosted-transport concern: hosted/preview/production ship only use client islands and render server components via the /_veryfront/rsc/ endpoint, so refusing a plain server-component page as a browser module is correct there. A local veryfront dev project has no client flight consumer — the browser hydrates by importing the whole page module, exactly as the non-RSC path does (which still works because isRSCEnabled is false there). So the hosted admission refused the very module the local hydration pipeline requests → 404 → dead hydration.

(Flipping the client-module strategy to rsc-module was ruled out: the RSC module endpoint also enforces requireClientBoundary, so it 404s server components too. The break is purely in module admission.)

Fix

Scope requiresClientBoundary to non-local projects via a new isLocalProject input on BrowserModuleSourcePolicyOptions:

requiresClientBoundary: options.rscEnabled === true
  && appRelative !== null
  && options.isLocalProject !== true,

module-server.ts passes isLocalProject: options.isLocalProject into the classifier. Local dev now serves app-router pages/layouts through the same plain-serve branch the non-RSC path already uses, so they hydrate. Keeping rscEnabled truthful (rather than forcing it false in local dev) means any future rscEnabled-dependent behavior can't silently regress local dev.

Non-regressing:

• Hosted contract unchanged — isLocalProject: false ⇒ requiresClientBoundary stays true ⇒ server components still 404. Pinned by the existing requires an explicit client boundary for RSC app modules test.
• Server surfaces still protected in local dev — api/actions/server-route/middleware/metadata protections are independent of rscEnabled.

Tests (red→green)

Added serves RSC app-router page and layout modules in local dev so they hydrate to module-server.test.ts (mirrors the hosted pinned test, isLocalProject: true): asserts app/page.js + app/layout.js serve 200 with their server markers, and that app/api/save.js stays 404. Fails on main (404), passes with the fix. Full module-server + browser-module-admission + client-module-strategy + endpoint-router suites green; deno check/lint/fmt + docs:api-reference:check clean.

Closes #3662.

[coderabbitai]

Warning

Review limit reached

@mattboon, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 2 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 86f16c5e-3f53-473a-b03c-7755dc7a6b24

📥 Commits

Reviewing files that changed from the base of the PR and between 76ef22c and dd5936f.

📒 Files selected for processing (3)

• src/modules/server/browser-module-admission.ts
• src/modules/server/module-server.test.ts
• src/modules/server/module-server.ts

---

_{Comment @coderabbitai help to get the list of available commands.}