fix(app-router): pass searchParams to layout generateMetadata

[NathanDrake2406]

Summary

• Layout generateMetadata() was always called with undefined for searchParams because the spObj (URLSearchParams → plain object conversion) was constructed after the layout metadata loop — only the page segment received the real query parameters.
• Fix: hoist spObj construction to before the layout loop so all layouts receive the same search params object already correctly used by the page.
• Adds a regression fixture (tests/fixtures/app-basic/app/layout-metadata-search/) and a test asserting that layout generateMetadata() title reflects the URL query parameter value, not the undefined-fallback default.

Root Cause

In packages/vinext/src/entries/app-rsc-entry.ts, the layout loop called:

resolveModuleMetadata(layoutMods[i], params, undefined, parentForThisLayout)

while the page call (a few lines later) correctly used spObj. The spObj variable simply wasn't constructed yet when the loop ran.

Test Plan

• New test: layout generateMetadata() receives searchParams from URL query string — verifies ?tab=settings produces <title>Layout Section: settings</title> from the layout's generateMetadata
• All existing metadata tests still pass (vp test run tests/app-router.test.ts -t "metadata|generateMetadata|viewport" — 26 tests green)
• vp check passes (format, lint, types)

[pkg-pr-new]

Open in StackBlitz

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

commit: 15a3067

[Copilot]

Pull request overview

Fixes App Router metadata resolution so searchParams from the URL query string are passed consistently to layout generateMetadata() (previously layouts always received undefined, while pages received the real params), and adds a regression fixture + test to prevent regressions.

Changes:

• Hoist URLSearchParams → plain object conversion so layout metadata resolution receives the same searchParams object as the page.
• Add a new layout-metadata-search fixture whose layout generateMetadata() reads searchParams.tab.
• Add an integration test asserting the layout-derived <title> reflects the query string value.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
packages/vinext/src/entries/app-rsc-entry.ts	Hoists searchParams object construction before layout metadata resolution and passes it into resolveModuleMetadata() for layouts.
tests/fixtures/app-basic/app/layout-metadata-search/layout.tsx	New regression fixture: layout generateMetadata() reads searchParams.tab and sets the title accordingly.
tests/fixtures/app-basic/app/layout-metadata-search/page.tsx	New fixture page to complete the route under the test layout.
tests/app-router.test.ts	New regression test asserting layout metadata uses query string search params.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

When converting URLSearchParams into spObj, using a normal {} plus if (k in spObj) allows inherited/prototype keys (e.g. __proto__, constructor, toString) to be treated as existing properties. This can lead to surprising behavior and can open up prototype-related issues when passing spObj into userland generateMetadata().

Consider creating spObj with Object.create(null) and using Object.prototype.hasOwnProperty.call(spObj, k) (or checking spObj[k] !== undefined) instead of the in operator when handling duplicates.

Suggested change

	const spObj = {};
	let hasSearchParams = false;
	if (searchParams && searchParams.forEach) {
	searchParams.forEach(function(v, k) {
	hasSearchParams = true;
	if (k in spObj) {
	const spObj = Object.create(null) as Record<string, string | string[]>;
	let hasSearchParams = false;
	if (searchParams && searchParams.forEach) {
	searchParams.forEach(function(v, k) {
	hasSearchParams = true;
	if (Object.prototype.hasOwnProperty.call(spObj, k)) {

[james-elicx]

/bigbonk review

[ask-bonk]

Review Summary

The bug identification is correct — spObj was constructed after the layout metadata loop, so layouts always received undefined for searchParams. The fix (hoisting spObj construction) is the right mechanical change, and the test + fixture are well-structured.

However, the fix introduces a Next.js behavioral divergence: in Next.js, layouts do not receive searchParams in generateMetadata() — only pages do. The original code was accidentally correct for the wrong reason (passing undefined). This PR makes it intentionally wrong by passing real search params to layouts.

Next.js behavior (authoritative source)

In packages/next/src/lib/metadata/resolve-metadata.ts, the props construction is:

const props: SegmentProps = isPage ? { params, searchParams } : { params }

Layouts get { params } only. Pages get { params, searchParams }. This applies to both generateMetadata() and generateViewport().

See also the Next.js docs for generateMetadata:

searchParams - An object containing the current URL's search parameters. Only available in pages.

What should happen

1. The spObj hoisting is still correct and necessary — it should be constructed before the layout loop so it's available for both the layout and page metadata calls.
2. But the layout metadata call should pass undefined (not spObj) to match Next.js semantics.
3. Only the page's resolveModuleMetadata call (line 1000) should receive spObj.
4. The test fixture should be updated to test the page's generateMetadata receiving searchParams, or to verify that the layout does not receive them (matching Next.js).

The spObj hoisting is still useful for the page call and for pageProps.searchParams, so the structural change is fine — just don't pass it to layout metadata resolution.

[ask-bonk]

Next.js parity issue: In Next.js, generateMetadata() for layouts does not receive searchParams — only pages do. The props construction in Next.js's resolve-metadata.ts is:

const props = isPage ? { params, searchParams } : { params }

Passing spObj here diverges from Next.js behavior. The original undefined was accidentally correct (though for the wrong reason — it should have been an intentional choice, not a sequencing bug).

Suggested change

	const metaPromise = resolveModuleMetadata(layoutMods[i], params, spObj, parentForThisLayout)
	const metaPromise = resolveModuleMetadata(layoutMods[i], params, undefined, parentForThisLayout)

The spObj hoisting is still the right structural change — it needs to be available for the page metadata call on line 1000 and for pageProps.searchParams below. Just don't pass it to layouts.

[ask-bonk]

Since Next.js does not pass searchParams to layout generateMetadata(), this fixture tests behavior that diverges from Next.js.

Consider either:

1. Converting this into a page-level generateMetadata test (testing that the page receives searchParams correctly), or
2. Keeping this as a layout fixture but asserting the opposite — that the layout's metadata falls back to "home" because searchParams is not provided to layouts (matching Next.js behavior).

Option 2 would be a useful parity test to prevent future accidental passing of searchParams to layouts.

[ask-bonk]

This assertion expects searchParams to be available in the layout's generateMetadata, which contradicts Next.js behavior. In Next.js, this would produce <title>Layout Section: home</title> (the fallback) because layouts don't receive searchParams.

If the goal is Next.js parity, this should assert the fallback:

Suggested change

	expect(html).toContain("<title>Layout Section: settings</title>");
	expect(html).toContain("<title>Layout Section: home</title>");

Alternatively, if you want to test that searchParams works for page metadata, add a generateMetadata to the page fixture instead and assert on that.

[ask-bonk]

Review submitted. Here's a summary of the findings:

The core bug identification is correct — spObj was constructed after the layout metadata loop, so layouts always received undefined. Hoisting it earlier is the right structural fix.

However, this PR introduces a Next.js behavioral divergence. In Next.js, generateMetadata() for layouts does not receive searchParams — only pages do. The Next.js source explicitly constructs props as isPage ? { params, searchParams } : { params }. The original undefined was accidentally correct behavior (for the wrong reason).

The review requests changes:

1. Keep the spObj hoisting (it's needed for the page call and pageProps.searchParams)
2. Revert the layout metadata call back to passing undefined instead of spObj
3. Update the test to either assert the layout falls back (matching Next.js) or test page-level generateMetadata instead

github run

[james-elicx]

/bigbonk review

[ask-bonk]

The PR looks good. The prior review feedback from ask-bonk has been fully addressed:

1. Next.js parity is correct — layout resolveModuleMetadata() passes undefined for searchParams (line 987), matching Next.js's isPage ? { params, searchParams } : { params } pattern. Only the page call (line 1001) receives spObj.
2. Object.create(null) is the right call — this addresses the Copilot prototype pollution concern. With a null-prototype object, k in spObj is safe since there are no inherited properties.
3. The spObj hoisting is structurally correct — it needed to move before the layout loop anyway because pageProps.searchParams (line 1018) references it, and the page metadata call (line 1001) needs it.
4. Test and fixture are well-structured — the test correctly asserts the fallback title "Layout Section: home", confirming layouts do NOT receive searchParams.
5. Consistency with app-page-boundary-render.ts — the extracted runtime helper at server/app-page-boundary-render.ts:124 already passes undefined for layouts, so both code paths are aligned.

One minor nit on the fixture page copy (non-blocking).

[ask-bonk]

Nit: This copy is stale after the parity fix — the test now verifies that layout generateMetadata does not receive searchParams.

Suggested change

	<p>This page tests that layout generateMetadata receives searchParams.</p>
	<p>This page tests that layout generateMetadata does NOT receive searchParams.</p>

[ask-bonk]

Review submitted. Here's a summary:

Approved — the PR correctly addresses the original review feedback and is ready to merge.

Key findings:

• The spObj hoisting is structurally correct and necessary for both the page metadata call and pageProps.searchParams
• Layout resolveModuleMetadata() correctly passes undefined (not spObj), matching Next.js parity where only pages receive searchParams in generateMetadata()
• Object.create(null) properly mitigates the prototype pollution concern raised by Copilot
• The test correctly asserts the fallback title, confirming layouts don't receive search params
• Both code paths (app-rsc-entry.ts and app-page-boundary-render.ts) are now consistent

One non-blocking nit: the fixture page's <p> text still says "tests that layout generateMetadata receives searchParams" when it should say "does NOT receive" — suggested a fix inline.

github run