refactor: extract template string code generation into entries/ modules

[yunus25jmi1]

Summary

Extract the 5 template string code generation functions from \index.ts\ and \�pp-dev-server.ts\ into dedicated modules under \packages/vinext/src/entries/.

Changes

New files (\packages/vinext/src/entries/)

File	Function	Lines
\�pp-rsc-entry.ts\	\generateRscEntry()\ + \AppRouterConfig\	2135
\�pp-ssr-entry.ts\	\generateSsrEntry()\	410
\�pp-browser-entry.ts\	\generateBrowserEntry()\	284
\pages-server-entry.ts\	\generateServerEntry()\	857
\pages-client-entry.ts\	\generateClientEntry()\	87

Modified files

• **\�pp-dev-server.ts**: Replaced 3034 lines with a 12-line re-export barrel (maintains backward API compatibility)
• **\index.ts**: Removed ~1238 lines of inline generators; imports from \�ntries/\ modules; call sites pass explicit params instead of relying on closure variables

Pages Router closure conversion

\generateServerEntry\ and \generateClientEntry\ were closures inside \�inext()\ that captured \pagesDir,
extConfig, and \middlewarePath. Converted to explicit function parameters.

Tests

• **\ ests/entry-templates.test.ts**: 9 snapshot tests covering all 5 generators + the re-export barrel

Verification

• Typecheck: pass
• Lint: pass
• Vitest: all tests pass (6 pre-existing failures unrelated to this change)

Closes #253

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/vinext@259

commit: c63f891

[yunus25jmi1]

@southpolesteve @threepointone @elithrar Kindly review the changes. The workflow is completely green. All checks are passed with 12 successful checks & 3 skipped.

[southpolesteve]

/bigbonk review please

[ask-bonk]

@southpolesteve Bonk workflow was cancelled.

View workflow run · To retry, trigger Bonk again.

[yunus25jmi1]

@southpolesteve, @james-elicx review the changes.

[james-elicx]

To be honest I think it would probably be best to do this incrementally (starting with snapshots) in PRs rather than an all-at-once PR to avoid the risk of regressions due to our fast pace of change

[yunus25jmi1]

Thanks @james-elicx ! Could you clarify what you'd like to see as a starting point — are you thinking snapshot tests first as a separate PR, then the extractions follow? Just want to make sure I structure the follow-ups in a way that works for the team's review cadence.

[james-elicx]

Yeah lets get the snapshot tests in first, then do each of the extractions after separately so that we can have strong confidence

[southpolesteve]

I should add some context about why I think this is important refactor. When I was looking at the codebase shortly after launch and trying to understand where AI was struggling, one of the things I saw was it really seemed to struggle around having mission critical code sitting inside generated template string. I do think its something we need to change.

But at the same time, I do agree with @james-elicx its also important to take our time with. Getting this wrong could really break things in a subtle way

[yunus25jmi1]

Thanks @james-elicx @southpolesteve — totally agree on the incremental approach. I've opened #345 with snapshot tests for all 5 generators as the first step. Once that merges, I'll follow up with individual extraction PRs (one per generator), so each change is small and the snapshots catch any drift.

Plan:

1. Snapshot tests → test: add snapshot tests for entry template generators #345 (ready for review)
2. Extract generateSsrEntry → entries/app-ssr-entry.ts
3. Extract generateBrowserEntry → entries/app-browser-entry.ts
4. Extract generateRscEntry → entries/app-rsc-entry.ts
5. Extract generateServerEntry → entries/pages-server-entry.ts (closure → explicit params)
6. Extract generateClientEntry → entries/pages-client-entry.ts (closure → explicit params)
   I'll close this PR in favor of the incremental series. Each extraction PR will be small enough to review confidently, and the snapshot tests from test: add snapshot tests for entry template generators #345 will guard against subtle regressions.

[yunus25jmi1]

Closing this in favor of the incremental approach discussed with @james-elicx and @southpolesteve.

The all-at-once extraction is too risky given the fast pace of changes on main. Instead, I'll land this as a series of small, focused PRs — each one guarded by the snapshot tests from #345.

Incremental plan:

1. Snapshot tests → test: add snapshot tests for entry template generators #345 (ready for review)

   • Locks down the generated output of all 5 generators before any extraction begins
   • 9 tests covering \generateRscEntry, \generateSsrEntry, \generateBrowserEntry, \generateServerEntry, \generateClientEntry\

2. *Extract \generateSsrEntry* → \�ntries/app-ssr-entry.ts\

   • Simplest extraction — zero parameters, self-contained
   • \�pp-dev-server.ts\ becomes a re-export for this function

3. *Extract \generateBrowserEntry* → \�ntries/app-browser-entry.ts\

   • Also zero parameters, self-contained
   • Another straightforward move

4. *Extract \generateRscEntry* → \�ntries/app-rsc-entry.ts\

   • Largest generator (~2200 lines), but already a standalone exported function
   • Moves \AppRouterConfig\ interface along with it

5. *Extract \generateServerEntry* → \�ntries/pages-server-entry.ts\

   • Currently a closure inside \�inext()\ capturing \pagesDir,
     extConfig, \middlewarePath\
   • Requires converting closure variables to explicit function parameters
   • Snapshot tests catch any parameter-passing mistakes

6. *Extract \generateClientEntry* → \�ntries/pages-client-entry.ts\

   • Same closure-to-params conversion as above, but much smaller (~80 lines)

Each PR will be small enough to review confidently. The snapshot tests from step 1 ensure that the generated output remains identical after each extraction — any accidental change to the template strings will show up as a snapshot diff.

[yunus25jmi1]

Superseded by the incremental extraction series. See the plan above.