Skip to content

Fix transformed Server Function source locations #1361

Description

@hi-ogawa

UPDATE:
After #1355, the only incorrect mapping is inline directive with Vite 8.
Minimal reproduction is in https://github.com/hi-ogawa/reproductions/tree/main/vite8-inline-hoist-sourcemap-repro

#1358 revealed some incorrect user-facing source map behaviors. This is to track those issues.

// These zero-based expectations record current behavior, including approximate
// locations. Improving a mapping should update its expectation as a follow-up.
// https://github.com/vitejs/vite-plugin-react/issues/1361
const serverReferenceCases: {
route: string
references: ReferenceCase[]
}[] = [


Motivation

Issue #1356 and PR #1358 establish browser-level CDP coverage for development source locations of transformed Server Functions. The resulting expectation matrix records the current behavior and reveals several transforms whose generated registerServerReference(...) callsite does not map to a useful original source position.

This issue tracks fixing those mappings. It is separate from #1356, whose purpose is to establish the fixture and regression infrastructure, and narrower than the transform redesign discussed in #1350.

Current behavior

The source-map E2E currently records these approximate or inaccurate locations:

  • Named and anonymous default function exports resolve to the closing brace of the declaration.
  • A local export alias resolves to the closing brace of its local function declaration.
  • A re-export and expanded export * resolve to the module-level "use server" directive rather than their export statements.
  • An inline directive function resolves to the rendered <section> rather than the directive-bearing function.

These expectations intentionally preserve the current state so unrelated changes cannot silently regress working forms. They should be updated as each mapping is corrected.

Expected behavior

Development tooling should navigate to a useful source site for each Server Function:

  • Default function exports should resolve to their declaration or export.
  • Local aliases should resolve to the local declaration or export specifier.
  • Re-exports may resolve to the re-export statement as an acceptable approximation.
  • Inline directives should resolve to the directive-bearing function.

Direct named exports, variable exports, TypeScript/TSX exports, multiple exports, default identifier exports, and client-imported Server References already have useful recorded locations and must remain stable.

Implementation context

  • transformWrapExport appends registration code for defaults and export specifiers, which can leave the generated call without a useful source mapping.
  • transformExpandExportAll feeds the re-export path before wrapping.
  • transformHoistInlineDirective moves inline functions and emits registration at the original site, whose composed map currently resolves elsewhere in the component.
  • Rework transformWrapExport and transformHoistInlineDirective #1350 may change these lowering shapes, but this issue concerns the developer-facing mapping regardless of the generated implementation.

Verification

Update the corresponding current-state expectations in packages/plugin-rsc/e2e/source-map.test.ts while keeping the complete Server Reference matrix passing.

Non-goals

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions