next.js

886f543a - fix(ppr): fix prerender info matching for rewritten paths (#83359)

fix(ppr): fix prerender info matching for rewritten paths (#83359) ## What? Fixed prerender info matching for rewritten paths in App Router by using `resolvedPathname` instead of `parsedUrl.pathname` in the app-page template. ## Why? Previously, the app-page template used `parsedUrl.pathname` to match against `prerenderManifest` routes. However, when middleware rewrites paths, `parsedUrl.pathname` contains the original (unrewritten) path, while `resolvedPathname` contains the actual path that should be used for prerender lookup. This mismatch caused incorrect prerender behavior for routes that were rewritten by middleware, as the handler would look up prerender info using the wrong path. This handling is special cased for when not handling an interception route when cache components is not enabled. This work is being tracked in NAR-335. ## How? - **Modified `packages/next/src/build/templates/app-page.ts`**: - Removed unused `parsedUrl` parameter from handler function - Updated prerender info matching to use `resolvedPathname` instead of `parsedUrl.pathname` - Added explanatory comment about why `resolvedPathname` is the correct choice - **Added comprehensive test suite** in `test/e2e/app-dir/sub-shell-generation-middleware/`: - Tests various middleware rewrite scenarios - Validates sub-shell generation behavior with nested dynamic routes - Tests both static and dynamic prerender scenarios - Includes middleware that rewrites paths to different route structures - **Enhanced deploy testing** in `test/lib/next-modes/next-deploy.ts`: - Added `stderr: 'inherit'` to provide earlier deployment feedback - Improves debugging experience for deployment-related tests The fix ensures that prerender info lookup works correctly for all paths, whether they're rewritten by middleware or not, providing consistent behavior across different routing scenarios. Fixes #83354