`@vitejs/plugin-rsc` 0.5.31 breaks consumers of `serverReferenceMetaMap`

[hi-ogawa]

Was testing out Vinext locally and found out #1310 broke it.

---

Description

@vitejs/plugin-rsc 0.5.31 replaced RscPluginManager.serverReferenceMetaMap with RscPluginManager.serverReferences.metaMap as part of the server-reference claims work in #1310.

This breaks the latest published Vinext release during production builds. Vinext 1.0.0-beta.4 declares @vitejs/plugin-rsc: ^0.5.26, so a fresh installation can resolve plugin-RSC 0.5.31 even though Vinext still reads manager.serverReferenceMetaMap.

Reproduction

Install these published versions in a minimal Vinext App Router application containing a server action:

{
  "dependencies": {
    "@vitejs/plugin-react": "6.0.4",
    "@vitejs/plugin-rsc": "0.5.31",
    "react": "19.2.7",
    "react-dom": "19.2.7",
    "react-server-dom-webpack": "19.2.7",
    "vinext": "1.0.0-beta.4",
    "vite": "8.1.5"
  }
}

Then run:

pnpm install
pnpm exec vinext build

The first two scan builds complete, but the final RSC build fails:

[3/5] build rsc environment...

TypeError: Cannot convert undefined or null to object
    at Function.keys (<anonymous>)
    at resolveHasServerActions (.../vinext/dist/index.js:865:17)

Pinning plugin-RSC to 0.5.30 makes the same application build successfully with stock Vite 8.1.5.

Cause

In plugin-RSC 0.5.30, the experimental manager exposes:

serverReferenceMetaMap: Record<string, ServerReferenceMeta>

In 0.5.31, the metadata moved to:

serverReferences: ServerReferencesManager

// ServerReferencesManager
metaMap: Map<string, ServerReferenceMeta>

The new manager supports multiple server-reference claim owners, but the old property is now undefined. Existing consumers that call Object.keys() or Object.values() on it fail at build time.

Expected Behavior

A package version accepted by Vinext's published plugin-RSC peer range should not crash a production build because the manager metadata property disappeared.

RscPluginManager is marked experimental, so changing its shape may be intentional. However, plugin-RSC 0.5.31 is currently installable into the latest published Vinext release without a peer warning, which turns the API migration into a fresh-install runtime failure.

Possible Resolution

Could plugin-RSC temporarily expose a deprecated read compatibility accessor for serverReferenceMetaMap, derived from serverReferences.metaMap?

For example:

/** @deprecated Use serverReferences.metaMap. */
get serverReferenceMetaMap(): Record<string, ServerReferenceMeta> {
  return Object.fromEntries(this.serverReferences.metaMap)
}

A getter is preferable to assigning a field alias because ServerReferencesManager replaces metaMap whenever claims change. The getter always reflects the current derived map.

This would cover Vinext's existing read operations through Object.keys(), Object.values(), and keyed lookup. It would intentionally not preserve direct mutation of the old record. Vinext only reads the property, so read compatibility is sufficient for the concrete released-package break.

Alternatively, if compatibility should be handled entirely in Vinext, it would help to document the manager migration and coordinate package constraints so incompatible plugin-RSC versions produce an installation warning rather than a build-time TypeError.

Related change: vite-plugin-react PR #1310