[PR #966] [MERGED] refactor: extract app rsc manifest construction #986

Closed
opened 2026-05-06 13:11:24 +02:00 by BreizhHardware · 0 comments

📋 Pull Request Information

Original PR: https://github.com/cloudflare/vinext/pull/966
Author: @NathanDrake2406
Created: 4/29/2026
Status: Merged
Merged: 4/29/2026
Merged by: @james-elicx

Base: mainHead: nathan/extract-generated-manifest-construction


📝 Commits (1)

  • e07ecd7 refactor: extract app rsc manifest construction

📊 Changes

3 files changed (+451 additions, -210 deletions)

View changed files

📝 packages/vinext/src/entries/app-rsc-entry.ts (+15 -210)
packages/vinext/src/entries/app-rsc-manifest.ts (+264 -0)
📝 tests/entry-templates.test.ts (+172 -0)

📄 Description

Summary

Extracts the App Router RSC generated-manifest construction out of generateRscEntry() into app-rsc-manifest.ts.

The generator now treats the app shape as an explicit construction boundary:

  • route module import allocation
  • route entry serialization
  • root fallback/global-error module references
  • metadata route entries
  • generateStaticParams map entries

generateRscEntry() keeps request/runtime codegen ownership and consumes the manifest-construction result.

Why

app-rsc-entry.ts had accumulated app-shape responsibilities inside the top-level RSC entry generator. That made the generated runtime path harder to review because file-system route shape, module import allocation, metadata route handling, and request lifecycle code all lived in one function.

This mirrors the separation Next.js keeps between its generated App Router tree shape and the runtime route module that consumes it:

Vinext still uses its own scanned AppRoute model, but this PR makes the equivalent app-shape-to-generated-manifest step explicit and testable.

Notes

Static metadata files are now read through the extracted manifest helper. If a discovered static metadata file cannot be read, the helper throws a build-time error with the file path instead of generating an empty runtime response.

Tests

  • vp test run tests/entry-templates.test.ts
  • vp check
  • vp run vinext#build
  • commit hook: vp check --fix, knip --no-progress

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/cloudflare/vinext/pull/966 **Author:** [@NathanDrake2406](https://github.com/NathanDrake2406) **Created:** 4/29/2026 **Status:** ✅ Merged **Merged:** 4/29/2026 **Merged by:** [@james-elicx](https://github.com/james-elicx) **Base:** `main` ← **Head:** `nathan/extract-generated-manifest-construction` --- ### 📝 Commits (1) - [`e07ecd7`](https://github.com/cloudflare/vinext/commit/e07ecd7e7621d7d288d5530fb3e78299d0762d79) refactor: extract app rsc manifest construction ### 📊 Changes **3 files changed** (+451 additions, -210 deletions) <details> <summary>View changed files</summary> 📝 `packages/vinext/src/entries/app-rsc-entry.ts` (+15 -210) ➕ `packages/vinext/src/entries/app-rsc-manifest.ts` (+264 -0) 📝 `tests/entry-templates.test.ts` (+172 -0) </details> ### 📄 Description ## Summary Extracts the App Router RSC generated-manifest construction out of `generateRscEntry()` into `app-rsc-manifest.ts`. The generator now treats the app shape as an explicit construction boundary: - route module import allocation - route entry serialization - root fallback/global-error module references - metadata route entries - `generateStaticParams` map entries `generateRscEntry()` keeps request/runtime codegen ownership and consumes the manifest-construction result. ## Why `app-rsc-entry.ts` had accumulated app-shape responsibilities inside the top-level RSC entry generator. That made the generated runtime path harder to review because file-system route shape, module import allocation, metadata route handling, and request lifecycle code all lived in one function. This mirrors the separation Next.js keeps between its generated App Router tree shape and the runtime route module that consumes it: - Next.js app-page template receives an injected `tree` and passes it as `userland.loaderTree`: [packages/next/src/build/templates/app-page.ts](https://github.com/vercel/next.js/blob/e1bb911c14e4ea3c6bb8cc98871ffdee317d513f/packages/next/src/build/templates/app-page.ts#L100-L138) - Next.js `LoaderTree` makes segment modules and parallel routes explicit: [packages/next/src/server/lib/app-dir-module.ts](https://github.com/vercel/next.js/blob/e1bb911c14e4ea3c6bb8cc98871ffdee317d513f/packages/next/src/server/lib/app-dir-module.ts#L6-L28) - Next.js parses loader-tree shape through a dedicated helper: [packages/next/src/shared/lib/router/utils/parse-loader-tree.ts](https://github.com/vercel/next.js/blob/e1bb911c14e4ea3c6bb8cc98871ffdee317d513f/packages/next/src/shared/lib/router/utils/parse-loader-tree.ts#L4-L20) - Build-time static path logic traverses that tree, including parallel routes: [packages/next/src/build/static-paths/utils.ts](https://github.com/vercel/next.js/blob/e1bb911c14e4ea3c6bb8cc98871ffdee317d513f/packages/next/src/build/static-paths/utils.ts#L113-L193) Vinext still uses its own scanned `AppRoute` model, but this PR makes the equivalent app-shape-to-generated-manifest step explicit and testable. ## Notes Static metadata files are now read through the extracted manifest helper. If a discovered static metadata file cannot be read, the helper throws a build-time error with the file path instead of generating an empty runtime response. ## Tests - `vp test run tests/entry-templates.test.ts` - `vp check` - `vp run vinext#build` - commit hook: `vp check --fix`, `knip --no-progress` --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
BreizhHardware 2026-05-06 13:11:24 +02:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/vinext#986
No description provided.