mirror of
https://github.com/hanzoai/next.js.git
synced 2026-09-24 17:00:51 +00:00
canary
100
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
34759c3e1a |
router instrumentation: add transition start context (2/7) (#94766)
## Stack Position (2/7) in the router instrumentation stack. 1. #94755: router instrumentation: refactor client hook dispatch (1/7) 2. **#94766: router instrumentation: add transition start context (2/7)** 3. #94756: router instrumentation: add transition commit events (3/7) 4. #94765: router instrumentation: add commit route and prefetch context (4/7) 5. #94757: router instrumentation: add transition abort events (5/7) 6. #94758: router instrumentation: add route mismatch events (6/7) 7. #94737: router instrumentation: add transition settlement events (7/7) Parent: #94755 Next: #94756 ## What This PR Does Adds an experimental third argument to the existing start hook: ```ts export function onRouterTransitionStart(url, navigationType, event) {} ``` The event contains: - `id` and framework-captured Unix `timestamp` in milliseconds - `fromRoutes`: route patterns visible when navigation is dispatched - `prefetchIntent`: `full`, `auto`, or `none` The primary `children` route is first, followed by visible parallel slots in deterministic order. ## Design Start owns the context that is authoritative before navigation work begins: the screen being left and the caller's prefetch intent. Destination routes and the cache result actually used are reported by commit instead. Consumers correlate them by transition ID. Without `experimental.instrumentationClientRouterTransitionEvents`, the existing two-argument hook behavior is unchanged. ## Not In This PR - Destination routes or observed prefetch result - Commit, abort, mismatch, or settled hooks ## Reviewer Focus - Route pattern extraction, including dynamic and parallel routes - Primary route ordering - Link intent propagation and experimental gating ## Validation - `pnpm build-all` - `pnpm --filter=next build` - App Router instrumentation client E2E: 15/15 <!-- NEXT_JS_LLM_PR --> --------- Co-authored-by: Jude Gao <[email protected]> |
||
|
|
8b57e82a14 |
router instrumentation: refactor client hook dispatch (1/7) (#94755)
## Stack Position (1/7) in the router instrumentation stack. 1. **#94755: router instrumentation: refactor client hook dispatch (1/7)** 2. #94766: router instrumentation: add transition start context (2/7) 3. #94756: router instrumentation: add transition commit events (3/7) 4. #94765: router instrumentation: add commit route and prefetch context (4/7) 5. #94757: router instrumentation: add transition abort events (5/7) 6. #94758: router instrumentation: add route mismatch events (6/7) 7. #94737: router instrumentation: add transition settlement events (7/7) ## What This PR Does Refactors client instrumentation loading so webpack and Turbopack provide an ordered array of instrumentation modules to a shared router-transition dispatcher. The existing config remains unchanged: ```ts const nextConfig = { instrumentationClientInject: ['my-observability-library/client'], } ``` ## Motivation This refactor lands first, ahead of the new lifecycle events, for two reasons: 1. **Maintainability — the stack adds more hooks.** Previously the hook fan-out was generated at build time (a composed `onRouterTransitionStart` emitted by both the webpack loader and the Turbopack import map). Each new event (commit, settled, abort, mismatch) would require regenerating that composition in both bundlers, per hook. Moving dispatch into one runtime module means new hooks are added once, in a single place, with no new bundler composition logic per hook. 2. **Fault tolerance.** Dispatch now isolates failures across instrumentation modules: - A hook that throws is caught per module, so the remaining modules still run for that navigation (previously, one throwing hook aborted the rest). - Modules whose exports are `null`/`undefined` (side-effect-only) are filtered out instead of throwing (previously an unguarded existence check could throw a `TypeError` and break hydration). ## Design - Injected modules run in array order before the application instrumentation file. - With no injected modules, bundlers preserve the direct user instrumentation alias and the runtime normalizes it to a one-element array. - Hooks are read from each module at dispatch time. - A failing hook does not prevent later modules from running. - Side-effect-only modules may export `null` or `undefined`. - The dispatcher can support additional hooks without generating new bundler composition logic for each hook. ## Not In This PR - New event arguments or lifecycle hooks - Transition IDs, timestamps, route data, or prefetch data ## Reviewer Focus - Webpack and Turbopack produce the same ordered module array. - Hook fan-out stays in the router-transition dispatcher. - Ordering, dynamic hook lookup, and per-module error isolation are preserved. ## Validation - `pnpm --filter=next types` - `cargo fmt --all -- --check` - Instrumentation client E2E coverage in dev and production with webpack and Turbopack - Cache Components instrumentation client coverage <!-- NEXT_JS_LLM_PR --> Co-authored-by: Jude Gao <[email protected]> |
||
|
Jimmy LaiandGitHub
|
4167e1f135 |
Docs: add signed commit guidance (#93155)
## What? Adds contributor-facing guidance for the new signed-commit requirement. - adds a `Signed commits` section to `contributing.md` - adds a short signed-commit note to the PR template - clarifies that a `Signed-off-by` line is not enough ## Why? As signed commits become required, contributors need a clear explanation in the repo and at PR time so they know what will be enforced and how to recover from unsigned commits. ## How? Documents the requirement in the main contribution guide and repeats the key action items in the PR checklist. ## Testing - docs-only change - verified with local readback and diff review <!-- NEXT_JS_LLM_PR --> |
||
|
|
931868b86c |
docs: add guide for displaying dates without hydration flash (#92786)
<!-- CURSOR_AGENT_PR_BODY_BEGIN -->
### What?
Adds a new documentation guide at
`docs/01-app/02-guides/displaying-dates.mdx` that documents how to
display locale-aware dates and times on prerendered/static pages without
a visible flash when the page loads.
### Why?
Dates and times formatted with `toLocaleDateString()` or
`Intl.DateTimeFormat` produce different output on the server (build-time
locale/timezone) vs the browser (user's locale/timezone). On prerendered
pages this causes a visible text change ("snap") when React hydrates and
re-renders with the correct locale.
There was no existing documentation for this common pattern. The inline
script approach (running a small `<script>` synchronously before browser
paint to correct the DOM) is the recommended technique for static/cached
pages.
### How?
**New guide** (`displaying-dates.mdx`) follows the progressive example
style from `public-static-pages.mdx`:
1. **Step 1**: Shows the problem — a static page with a server-formatted
date
2. **Step 2**: Fixes it with an inline `<script>` +
`suppressHydrationWarning`
3. **Step 3**: Extracts a reusable `<LocalDate>` component with `<time>`
element for accessibility/SEO
Also includes a comparison table for when to use alternative approaches
(`connection()`, Client Components with `useEffect`, fully dynamic
pages).
**Cross-references added:**
- `public-static-pages.mdx` — callout in the "Static components" section
where "the current time" is mentioned
- `connection.mdx` — callout noting the inline script alternative for
prerendered pages
### Improving Documentation
- Ran `prettier` to fix formatting
- Follows doc conventions (frontmatter, `switcher` pattern, `filename`
attributes, callout format)
<!-- NEXT_JS_LLM_PR -->
<!-- CURSOR_AGENT_PR_BODY_END -->
[Slack
Thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1776095579605699?thread_ts=1776095579.605699&cid=C03S8ED1DKM)
<div><a
href="https://cursor.com/agents/bc-e7710133-5c01-4a8a-9147-1ccbc9b6dd89"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source
media="(prefers-color-scheme: light)"
srcset="https://cursor.com/assets/images/open-in-web-light.png"><img
alt="Open in Web" width="114" height="28"
src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a> <a
href="https://cursor.com/background-agent?bcId=bc-e7710133-5c01-4a8a-9147-1ccbc9b6dd89"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source
media="(prefers-color-scheme: light)"
srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img
alt="Open in Cursor" width="131" height="28"
src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> </div>
---------
Co-authored-by: Cursor Agent <[email protected]>
Co-authored-by: Joseph Chamochumbi <[email protected]>
|
||
|
|
cb0d88f6e3 |
Improve existing dev server error message to suggest using it (#92317)
<!-- CURSOR_AGENT_PR_BODY_BEGIN --> ### What? Improves the error message shown when a user tries to start `next dev` while another dev server is already running in the same directory. ### Why? Previously, the error message only suggested killing the existing process (`Run kill <pid> to stop it.`). This wasn't the best advice — often the user just wants to access the already-running dev server rather than kill it and start a new one. ### How? Updated the error message in `packages/next/src/build/lockfile.ts` to present both options: 1. Access the existing server at its URL 2. Kill the process if they want to start a new one **Before:** ``` ✖ Another next dev server is already running. - Local: http://localhost:3000 - PID: 61479 - Dir: /path/to/project - Log: .next/dev/logs/next-development.log Run kill 61479 to stop it. ``` **After:** ``` ✖ Another next dev server is already running. - Local: http://localhost:3000 - PID: 61479 - Dir: /path/to/project - Log: .next/dev/logs/next-development.log You can access the existing server at http://localhost:3000, or run kill 61479 to stop it and start a new one. ``` Updated the lockfile test regex to match the new message format. <!-- CURSOR_AGENT_PR_BODY_END --> [Slack Thread](https://vercel.slack.com/archives/C046HAU4H7F/p1775173304387809?thread_ts=1775173304.387809&cid=C046HAU4H7F) <div><a href="https://cursor.com/agents/bc-0bb3085b-1fd1-56c3-8617-cd8a32d8c376"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a> <a href="https://cursor.com/background-agent?bcId=bc-0bb3085b-1fd1-56c3-8617-cd8a32d8c376"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> </div> --------- Co-authored-by: Cursor Agent <[email protected]> |
||
|
|
cc62489bbd |
docs: add verified adapters section (#91849)
## Summary - Introduces the **verified adapter** concept to deployment docs: open source adapters that run the Next.js compatibility test suite, hosted under the Next.js GitHub org - Splits the adapter list on the deploying page into **Verified Adapters** (Vercel, Bun) and **Other Platforms** (unverified integrations) - Documents the Next.js team's commitments for verified adapters and Ecosystem Working Group participants (coordinated testing, early access, direct support) - Notes that Cloudflare and Netlify are working on verified adapters built on the Adapter API ## Test plan - [ ] Verify links resolve correctly (adapter API reference, test suite anchor, ecosystem working group page) - [ ] Confirm markdown table renders properly with the longer "Varies" cell - [ ] Review wording with stakeholders (Cloudflare, Netlify, Bun) --------- Co-authored-by: Tim Neutkens <[email protected]> |
||
|
|
eb44c314dc |
docs: platform portability and infrastructure documentation (#91237)
## Summary Adds comprehensive documentation addressing platform partner feedback about Next.js portability, infrastructure requirements, and CDN caching. All technical claims verified against the codebase. **New pages (5):** - **Rendering Philosophy** — explains Next.js's component-level static/dynamic spectrum, framework comparisons, functional vs. performance fidelity definitions, CDN compatibility - **Deploying to Platforms** — feature support matrix (streaming/cache/edge requirements per feature), CDN infrastructure table, minimum requirements, adapter guidance - **How Revalidation Works** — tag system architecture (explicit + soft tags with `_N_T_` prefix), HTML/RSC consistency requirements, multi-instance coordination, graceful degradation - **CDN Caching** — cache variability (`Vary` headers, `_rsc` param), graceful degradation when headers are dropped, static prefetch caching (PPR-scoped), pathname-based cache keying direction - **PPR Platform Guide** — implementation tiers (origin-only through edge), resume protocol (`next-resume` header, POST + body), artifact storage, implementation checklist **Expanded pages (4):** - **Self-Hosting** — streaming infrastructure requirements, multi-instance cache coordination, CDN guide links, graceful shutdown details - **ISR** — multi-instance caveats, tag propagation, background regeneration billing, `x-nextjs-cache` monitoring - **Cache Handlers** — distributed tag coordination (Redis example), soft tags explanation, stream handling, error handling patterns - **Adapter API** — runtime integration context, PPR chain headers (`next-resume`), multi-instance cache entry propagation, fixed stale `x-nextjs-resume` comment ## Key corrections from code verification - Resume header is `next-resume`, not `x-nextjs-resume` (fixed in existing adapterPath docs too) - Resume requires POST with postponed state in body, not just a header - `x-nextjs-cache` has 4 values including `REVALIDATED`, only emitted outside minimal mode - Soft tags use `_N_T_` prefix with layout paths (`_N_T_/blog/layout`), not bare paths - `stale-while-revalidate` in Cache-Control is conditional on `expire` config - Static prefetch caching without state tree only works for PPR-enabled routes - Fastly product renamed from `Compute@Edge` to `Compute` --------- Co-authored-by: JJ Kasper <[email protected]> Co-authored-by: Tim Neutkens <[email protected]> |
||
|
|
058d950b15 |
ci: add node-stream test coverage workflow (#89861)
## Summary Run existing app-dir tests with `__NEXT_USE_NODE_STREAMS=true` in CI to validate the node stream rendering path alongside the default web stream path. - New CI job in `build_and_test.yml` that runs a curated set of app-dir tests with the flag enabled - `test/use-node-streams-tests-manifest.json`: manifest of tests to run in node-stream mode ## Test plan - [x] CI job triggers and runs tests successfully - [x] Does not affect existing CI jobs --------- Co-authored-by: Tim Neutkens <[email protected]> |
||
|
|
dfbc3dc6b7 |
Loading layout docs update (#90787)
<!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? This PR updates the documentation to clarify the interaction between `loading.js` and `layout.js`. ### Why? To address a common point of confusion and potential blocking navigation issues when layouts are dynamic. It provides clear guidance on how `loading.js` behaves relative to layouts and how to use `<Suspense>` for dynamic layout parts. ### How? - Added a "Good to know" callout in `loading.mdx` explaining that `loading.js` does not wrap the layout. - Introduced a new "Interaction with `loading.js`" section under Caveats in `layout.mdx`, including an explanation and a code example for wrapping dynamic layout components with `<Suspense>`. - Added a brief "Good to know" callout in `fetching-data.mdx` for consistency. Closes NEXT- Fixes # --> --- [Slack Thread](https://vercel.slack.com/archives/C05KYT5S9FF/p1772239839900129?thread_ts=1772239839.900129&cid=C05KYT5S9FF) <p><a href="https://cursor.com/agents/bc-d69fb736-2a00-5f68-9e28-9b31c194f12a"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a> <a href="https://cursor.com/background-agent?bcId=bc-d69fb736-2a00-5f68-9e28-9b31c194f12a"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> </p> --------- Co-authored-by: Cursor Agent <[email protected]> Co-authored-by: Joseph Chamochumbi <[email protected]> Co-authored-by: Delba de Oliveira <[email protected]> |
||
|
|
fe0bb2fc51 |
Next.js sticky scroll standards (#90197)
<!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - [x] Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - [x] Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> ### What? Adds documentation for handling sticky headers with Next.js navigation using `scroll-padding-top`. ### Why? Next.js's auto-scroll behavior explicitly skips sticky and fixed positioned elements. This can cause content to appear behind sticky headers when navigating to a hash fragment or using the `scroll` prop on `Link`. This documentation provides a web-standards solution using CSS `scroll-padding-top` to correctly position the scroll target. ### How? - Added a new "Handling sticky headers with `scroll-padding-top`" subsection to the `Link` component API reference (`docs/01-app/03-api-reference/02-components/link.mdx`) under the `scroll` prop. - Added a new "Scrolling with sticky headers" example to the "Linking and Navigating" guide (`docs/01-app/01-getting-started/04-linking-and-navigating.mdx`). --- [Slack Thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1771434038077029?thread_ts=1771434038.077029&cid=C03KAR5DCKC) <p><a href="https://cursor.com/background-agent?bcId=bc-cc4b24d5-0e73-5b36-84a3-f40e65064f7c"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> <a href="https://cursor.com/agents?id=bc-cc4b24d5-0e73-5b36-84a3-f40e65064f7c"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a></p> --------- Co-authored-by: Cursor Agent <[email protected]> Co-authored-by: Joseph Chamochumbi <[email protected]> |
||
|
|
9b6e563f7f |
refactor(app-render): extract stream-ops and debug-channel modules (5/8) (#89858)
## Summary Pure refactor: extract stream operations and debug-channel code from `app-render.tsx` into separate compile-time switchable modules. Web-only at this stage. - **`stream-ops.web.ts`**: extracted web stream operations (continueFizzStream, renderToFlightStream, renderToFizzStream, etc.) - **`stream-ops.ts`**: re-export switcher (web-only for now, conditional added in next PR) - **`debug-channel-server.web.ts`**: extracted web debug channel implementation - **`debug-channel-server.ts`**: re-export switcher - **`app-render.tsx`**: net reduction via imports from stream-ops/debug-channel instead of inline - **`node-web-streams-helper.ts`**: added `createRuntimePrefetchTransformStream` ## Test plan - [ ] `pnpm --filter=next types` passes - [ ] Existing app-dir e2e tests pass (smoke test: `pnpm test-dev-turbo test/e2e/app-dir/app/`) - [ ] No runtime behavior changes: identical web stream paths --------- Co-authored-by: Tim Neutkens <[email protected]> |
||
|
|
cf83d7c0b1 |
fix(cache): DCE to avoid pulling server internals into browser bundles (4/8) (#89865)
## Summary Fix dead-code elimination in `packages/next/cache.js` to prevent server-only internals from being pulled into browser bundles. Restructures the conditional exports so bundlers can properly tree-shake server paths. ## Test plan - [ ] `pnpm --filter=next build` succeeds - [ ] No runtime behavior changes --------- Co-authored-by: Tim Neutkens <[email protected]> |
||
|
Jimmy LaiandGitHub
|
def0e3aabf |
fix: use Buffer.indexOf in uint8array helpers for faster byte scanning (3/8) (#89864)
## Summary Use `Buffer.indexOf` when available in `uint8array-helpers.ts` for faster byte sequence scanning. Falls back to the existing manual loop on non-Node environments. ## Test plan - [ ] `pnpm test-unit test/unit/stream-utils/uint8array-helpers.test.ts` passes |
||
|
|
663c9151cf |
bench: render-pipeline benchmarks and stress routes (2/8) (#89863)
## Summary Benchmark infrastructure for measuring render pipeline performance. - **render-pipeline benchmark** (`bench/render-pipeline/`): `benchmark.ts` for profiling render paths, `analyze-profiles.ts` for CPU profile analysis - **Stress routes** (`bench/basic-app/app/streaming/`): light, medium, heavy, bulk, wide, chunkstorm variants for different streaming load profiles - **Basic app harness**: `benchmark.sh` runner script, `next.config.js` - **Minimal server**: `bench/next-minimal-server/bin/minimal-server.js` - **Docs**: `bench/BENCHMARKING.md` guide - **Config**: eslint exclusion for bench paths, package.json bench scripts ## Test plan - [ ] No runtime behavior changes - [ ] Benchmark scripts are standalone tooling --------- Co-authored-by: Tim Neutkens <[email protected]> |
||
|
|
a04d598f3c |
docs: agent skills, pr-status script, and AGENTS.md updates (1/8) (#89857)
## Summary - **Agent skills**: 9 new skill files in `.agents/skills/` covering DCE, flags, react-vendoring, runtime-debug, PR triage, and skill authoring - **PR status tooling**: `scripts/pr-status.js` script and `.claude/commands/pr-status.md` command - **AGENTS.md**: updated with skill references and development guidelines ## Test plan - [ ] No runtime behavior changes - [ ] Docs and tooling only --------- Co-authored-by: Tim Neutkens <[email protected]> |
||
|
|
26306e7f16 |
After() docs requests API (#89837)
<!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - [x] Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - [x] Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? Reworded the "With request APIs" section in the `after()` documentation. ### Why? To clearly differentiate when `cookies()` and `headers()` can be used inside `after()` in App Router pages (Server Components) versus Route Handlers/Server Functions, addressing potential confusion and potential runtime errors. ### How? - Split the "With request APIs" section into two subsections: "In Route Handlers and Server Functions" and "In Server Components (pages and layouts)". - Clarified that `cookies()`/`headers()` can be used directly in `after()` for Route Handlers/Server Functions. - Explained that `cookies()`/`headers()` *cannot* be used directly in `after()` for Server Components due to partial prerendering/Cache Components, and will throw a runtime error. - Added a new code example demonstrating the correct pattern for Server Components (reading request data *before* `after()` and passing it in). - Corrected `await` syntax in existing Route Handler examples and updated highlight line numbers. Closes NEXT- Fixes # --> --- [Slack Thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1770819029314169?thread_ts=1770819029.314169&cid=C03KAR5DCKC) <p><a href="https://cursor.com/background-agent?bcId=bc-73042547-63d7-59b4-8f69-6e569308d2e9"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> <a href="https://cursor.com/agents?id=bc-73042547-63d7-59b4-8f69-6e569308d2e9"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a></p> --------- Co-authored-by: Cursor Agent <[email protected]> Co-authored-by: Joseph Chamochumbi <[email protected]> |
||
|
|
fd5817d004 |
feat: add --experimental-cpu-prof flag for dev, build, and start (#87946)
## What Adds a `--experimental-cpu-prof` flag to `next dev`, `next build`, and `next start` commands to capture V8 CPU profiles for debugging performance bottlenecks. ## Why When investigating slow builds, slow dev server startups, or production server performance issues, having access to CPU profiles is invaluable. This provides a first-party way to capture these profiles without needing to manually set up the V8 inspector. ## How - Adds `--experimental-cpu-prof` flag to CLI commands - Uses V8's built-in CPU profiler via Node.js inspector module - Profiles are saved to `.next/cpu-profiles/` with descriptive filenames - Profiles are saved on process exit (Ctrl+C, SIGTERM, or normal exit) ### Profile files generated **`next dev`:** - `dev-main-*` - Parent process (dev server orchestration) - `dev-server-*` - Child server process (request handling and rendering) **`next build` (Turbopack):** - `build-main-*` - Main build orchestration process - `build-turbopack-*` - Turbopack compilation worker **`next build` (Webpack):** - `build-main-*` - Main build orchestration process - `build-webpack-client-*` - Client bundle compilation worker - `build-webpack-server-*` - Server bundle compilation worker - `build-webpack-edge-server-*` - Edge runtime compilation worker **`next start`:** - `start-main-*` - Production server process ## Changes addressing PR review comments - Removed signal handlers from `cpu-profile.ts` to prevent conflicts with CLI cleanup logic (telemetry, traces, etc.) - Added synchronous exit handler for non-signal process exits (errors, `process.exit()` calls) - CLI commands now explicitly call `saveCpuProfile()` as part of their cleanup before exiting - Replaced raw ANSI escape codes with `picocolors` library - Added comprehensive documentation about profile file naming for each command - Added build profiling test that verifies correct profile generation for both Turbopack and Webpack modes --------- Co-authored-by: Tim Neutkens <[email protected]> |
||
|
Jimmy LaiandGitHub
|
be6fcb250e |
perf: improve stats thresholds to reduce CI noise (#88158)
## Summary Add per-metric significance thresholds that account for variance. **Time metrics** (high variance from CI): - Dev boot: <100ms AND <15%, OR <3% - Build times: <500ms AND <5%, OR <2% **Size metrics** (deterministic): - node_modules: <10KB AND <1%, OR <0.01% - Bundle sizes: <2KB AND <1%, OR <0.1% ## Problem Current thresholds flag insignificant changes as regressions: - 3.45 KB change on 457 MB node_modules (0.0008%) was flagged as a regression ## Solution Use per-metric thresholds with OR logic for very small percentage changes: - Time metrics need more generous thresholds due to CI variance - Size metrics can be tighter since they're deterministic ## Test plan - Verify that 3.45 KB on 457 MB (0%) is now marked as insignificant - Verify that real regressions (>0.1% for sizes, >3% for times) are still flagged --- Stack: - #88157 - **→ This PR** |
||
|
Jimmy LaiandGitHub
|
43eead2337 |
ci: run stats on canary pushes for historical trend tracking (#88157)
## Summary - Add push trigger for canary branch to `pull_request_stats.yml` - Remove redundant `releaseStats` job from `build_and_deploy.yml` - Rename workflow/jobs from "PR Stats" to "Stats" ## Background The stats system was designed to save historical metrics to KV for trend tracking, but it wasn't working: 1. `releaseStats` job only ran on actual stable releases (rare) 2. When it did run, KV secrets were missing 3. PR stats had KV secrets but didn't save (because `isRelease=false`) This change consolidates stats into one workflow that runs on both PRs and canary pushes. ## Behavior **For PRs:** - Compare PR branch vs canary HEAD - Post comment to PR - Don't save to KV **For canary pushes:** - Compare current canary vs last stable release tag - Post comment to the commit - Save stats to KV for historical trend tracking ## Test plan - [ ] Verify workflow triggers on PR (existing behavior) - [ ] Verify workflow triggers on canary push (new behavior) - [ ] Verify stats are saved to KV on canary push - [ ] Verify trend sparklines appear in PR comments (once history builds up) |
||
|
Jimmy LaiandGitHub
|
4cd3ca26d7 |
perf: improve stats action reliability and reduce CI noise (#87945)
## Summary
Comprehensive improvements to the PR stats action for more reliable benchmarks and reduced CI noise.
### Vercel KV Integration
- Add `@vercel/kv` for historical data persistence
- Track metrics over time with `loadHistory()` / `saveToHistory()`
- Display trend sparklines in comments when history is available
### Comment Generation Refactor
- New `METRIC_LABELS` and `METRIC_GROUPS` configuration system
- Organized metrics by category (Dev Server, Production Builds, Production Runtime)
- Better formatting utilities (`prettifyTime`, `formatChange`, `generateTrendBar`)
- Bundle group totals for KV persistence
### Noise Reduction
- Significance thresholds: `50ms AND 10%` for time, `1KB AND 1%` for size
- Additional `<2%` filter for long-running operations (builds)
- Filters typical CI variance while catching real regressions
### Stats Config Updates
- Add `measureDevBoot: true` to enable dev boot benchmarks
- Fix `appDevCommand` to include `dev` subcommand
- Add `--webpack` flag to `appBuildCommand`
- Rename "Client Bundles (main, webpack)" to "Client Bundles (main)"
- Add `turbopack: {}` to test configs
### GitHub Actions Updates
- New `action.yml` with bundler input parameter
- Workflow improvements in `pull_request_stats.yml`
### New Files
- `scripts/test-stats-benchmark.sh` - Local testing script
- `.github/actions/next-stats-action/src/util/stats.js` - Shared stats utilities
- `.github/actions/next-stats-action/test-local.js` - Local comment testing
## Test Plan
```bash
cd .github/actions/next-stats-action
node test-local.js # Basic test
node test-local.js --with-history # Test with trend sparklines
```
|
||
|
Jimmy LaiandGitHub
|
a39366938a |
chore: add dev boot profiling and benchmark scripts (#87940)
## Summary Development scripts for profiling and benchmarking Next.js dev server boot time. ### Benchmarking Scripts - `benchmark-boot-time.sh` - Wall-clock benchmarking with two metrics: - **Listen time**: When TCP port accepts connections - **Ready time**: When first HTTP request succeeds - `benchmark-next-dev-boot.js` - Multi-iteration benchmarking with statistics (median, p95, stddev) ### Profiling Scripts - `profile-next-dev-boot.js` - CPU profiling infrastructure using V8 inspector - `analyze-profile.js` - Analyze CPU profiles to identify hot modules by CPU time ### Analysis Scripts - `analyze-dev-server-bundle.js` - Bundle analyzer for dev server (generates treemap report) - `trace-cli-startup.js` - Module loading trace to identify slow imports ## Usage ```bash # Benchmark dev server boot time (5 runs by default) ./scripts/benchmark-boot-time.sh # Multi-iteration benchmark with stats node scripts/benchmark-next-dev-boot.js --iterations 10 # Generate CPU profile node scripts/profile-next-dev-boot.js # Analyze profile output node scripts/analyze-profile.js .next/cpu-profiles/*.cpuprofile # Analyze dev server bundle node scripts/analyze-dev-server-bundle.js --open ``` ## Test Plan - [x] Run `./scripts/benchmark-boot-time.sh` locally - [x] Verify scripts execute without errors |
||
|
Jimmy LaiandGitHub
|
c5b19eb7f5 |
test: reduce flakiness in opentelemetry test for prod mode (#88102)
## Summary Reduces flakiness in the OpenTelemetry e2e test (`test/e2e/opentelemetry/instrumentation/opentelemetry.test.ts`) for production mode. ### Root Cause In production mode, Next.js generates additional spans from: - RSC prefetch requests (with `?_rsc` query param) - Edge runtime boundary spans These extra root spans cause `toMatchObject` assertions to fail because they receive more spans than expected. ### Changes 1. **Filter spans by expected `http.target`** in `expectTrace()`: - Extract expected `http.target` values from the match object - Filter root spans to only include those with matching targets - This excludes RSC prefetch and edge boundary spans that aren't part of the test assertion 2. **Fix TestExporter callback bug** in `instrumentation-test.ts`: - The success callback was called unconditionally (even after errors) - Added early `return` after error callback - Moved success callback inside the success path ## Test Plan - [x] All 34 tests pass in production mode (`NEXT_TEST_MODE=start`) - [ ] CI passes |
||
|
Jimmy LaiandGitHub
|
3c47bd99af |
chore: add Claude Code configuration (#87943)
adding basic config with graphite/repo instructions <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
|
c74cb2ae25 |
Redesign default error pages with cleaner, more user-friendly UI (#87988)
- redesigns the default global + default error boundaries. removing the WSOD forever :/ - adds dark mode support - unifies a bit of the styling - add the digest for the server error - adds a return button on the client errors <img width="3328" height="1914" alt="CleanShot 2026-01-02 at 09 46 36@2x" src="https://github.com/user-attachments/assets/9994eb37-c22b-4847-9a18-e9acf0ae6236" /> <img width="2144" height="1242" alt="CleanShot 2026-01-02 at 09 47 01@2x" src="https://github.com/user-attachments/assets/9b3bcf39-63f6-4c8d-85c5-2976c25f5b7b" /> <img width="2238" height="1632" alt="CleanShot 2026-01-02 at 09 47 17@2x" src="https://github.com/user-attachments/assets/436433d7-9873-496a-9c96-536e070be9d7" /> <img width="1708" height="1260" alt="CleanShot 2026-01-02 at 09 47 23@2x" src="https://github.com/user-attachments/assets/1ec42402-dbd9-41a3-801b-4745a4f128f7" /> --------- Co-authored-by: Claude Opus 4.5 <[email protected]> |
||
|
Jimmy LaiandGitHub
|
f3ccca39c7 |
chore: warn when running tests against stale build (#88001)
i got bit by this often :p <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
|
fa56f2c1fa |
fix: revalidateTag with profile should not trigger client cache invalidation (#88069)
## Summary
Fixes a bug where calling `revalidateTag(tag, profile)` incorrectly
triggers client-side cache invalidation, causing read-your-own-writes
behavior that violates stale-while-revalidate semantics.
### The Problem
When `revalidateTag('tag', 'max')` is called in a server action:
1. The tag is correctly marked for stale-while-revalidate
2. BUT the `x-action-revalidated` header is incorrectly set to `1`
3. This triggers client-side cache invalidation via
`revalidateEntireCache()`
4. The client navigates and may display stale data from background
revalidation
This caused the confusing behavior where:
- Click 1: Nothing happens (correct)
- Click 2: Nothing happens (correct)
- Click 3: Data changes to a stale value from click 1 (incorrect!)
### The Fix
In `addRevalidationHeader`, change the `isTagRevalidated` calculation to
only count tags **without** a profile (from `updateTag`). Tags with a
profile (from `revalidateTag`) should follow stale-while-revalidate
semantics and not trigger immediate client-side cache invalidation.
```typescript
// Before:
const isTagRevalidated = workStore.pendingRevalidatedTags?.length ? 1 : 0
// After:
const isTagRevalidated = workStore.pendingRevalidatedTags?.some(
(item) => item.profile === undefined
) ? 1 : 0
```
### Expected Behavior After Fix
| API | Profile | Header Set | Client Behavior |
|-----|---------|------------|-----------------|
| `updateTag(tag)` | `undefined` | ✅ Yes | Immediate refresh
(read-your-own-writes) |
| `revalidateTag(tag, 'max')` | `'max'` | ❌ No | Keep stale data (SWR) |
| `revalidateTag(tag, { expire: 0 })` | `{ expire: 0 }` | ✅ Yes* |
Immediate refresh |
*For immediate expiration via `pathWasRevalidated` which is already
handled correctly.
## Test Plan
- [x] Added new test page at
`test/e2e/app-dir/use-cache/app/(partially-static)/revalidate-tag-no-refresh/page.tsx`
- [x] Added test case that verifies 3 clicks of `revalidateTag` with
profile don't change the displayed value
- [x] Verified existing `updateTag` test (`should update after
revalidateTag correctly`) still passes
- [x] Verified both tests pass with `pnpm test-start`
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.5 <[email protected]>
|
||
|
|
69ae2c10e7 |
fix: normalize CRLF line endings in jscodeshift tests on Windows (#88008)
## Summary
Fixes flaky jscodeshift codemod tests on Windows CI (e.g.,
`next-async-request-api-dynamic-apis.test.js`,
`built-in-next-font.test.js`, `new-link.test.js`).
### Problem
Windows CI runners have `core.autocrlf=true` by default, which causes
test failures because:
1. Fixture files get checked out with CRLF line endings
2. jscodeshift's printer (recast) outputs CRLF on Windows
3. String comparison fails between expected and actual output
### Solution
Patches jscodeshift's test utilities in `jest-setup-after-env.ts`
(Windows only) to normalize line endings:
```typescript
const normalizeLF = (str: string) =>
str
.replace(/\r\n/g, '\n') // CRLF → LF
.replace(/[ \t]+$/gm, '') // Remove trailing whitespace per line
.replace(/\n*$/, '\n') // Ensure exactly one trailing newline
```
**Key changes:**
- **Patches `runInlineTest`** - Normalizes input, runs transform,
normalizes output, then compares
- **Patches `defineTest`** - Reads fixtures with normalization, uses
patched `runInlineTest`
- **Handles closure issue** - jscodeshift's internal functions use
closures that bypass exports, so we replace the functions entirely
Also includes a belt-and-suspenders `sed` command in the workflow to
strip CRLF from source files.
### Why not just fix `.gitattributes`?
The `.gitattributes` `eol=lf` setting helps, but doesn't solve the
problem because:
1. jscodeshift's recast printer uses platform-native line endings when
generating output
2. Fixture files may have inconsistent trailing whitespace/newlines
3. Self-hosted Windows runners may have different git configurations
### Follow-up
**TODO:** Configure Windows self-hosted runners with `git config
--system core.autocrlf false` so the `sed` workaround can be removed.
See the `TODO` comment in `build_reusable.yml`.
## Test Plan
- Windows CI unit tests should pass consistently
- Normalization only runs on Windows (`process.platform === 'win32'`)
- Other platforms unaffected
---------
Co-authored-by: Claude Opus 4.5 <[email protected]>
Co-authored-by: JJ Kasper <[email protected]>
|
||
|
|
942eb14d7c |
misc: fix type check log for CI envs (#87838)
this fixes the case where we would not show the typescritp check duration in a CI/non interactive env <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> --------- Co-authored-by: Tim Neutkens <[email protected]> |
||
|
|
8c271102dd |
Update Next.js auth docs examples (#86361)
<!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? Updated the `Layouts and auth checks` section in the authentication documentation (`docs/01-app/02-guides/authentication.mdx`). ### Why? The previous example demonstrating authentication checks within layouts was confusing and contradicted the documentation's own advice against this pattern. This update aims to provide clearer, recommended approaches for implementing authentication checks. ### How? - Removed the misleading layout-based authentication example. - Introduced a new subsection with an example showing authentication checks in a page component. - Added another new subsection with an example demonstrating authentication checks in a leaf component. - Enhanced the "Good to know" section with a reminder about the necessity of authorization checks for Server Actions. Closes NEXT- Fixes # --> --- [Slack Thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1763685748449029?thread_ts=1763685748.449029&cid=C03KAR5DCKC) <a href="https://cursor.com/background-agent?bcId=bc-f490a8eb-8f55-4a85-a31a-357adb24c09a"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/open-in-cursor-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/open-in-cursor-light.svg"><img alt="Open in Cursor" src="https://cursor.com/open-in-cursor.svg"></picture></a> <a href="https://cursor.com/agents?id=bc-f490a8eb-8f55-4a85-a31a-357adb24c09a"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/open-in-web-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/open-in-web-light.svg"><img alt="Open in Web" src="https://cursor.com/open-in-web.svg"></picture></a> Co-authored-by: Cursor Agent <[email protected]> |
||
|
|
5c8fdbe104 |
misc: allow beta to be triggered (#84713)
 - update codemod script - upgrade both release scripts, not sure which one is correct <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> --------- Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com> Co-authored-by: JJ Kasper <[email protected]> |
||
|
Jimmy LaiandGitHub
|
46709a2a0e |
docs: update revalidatePath, revalidateTag docs to be more consistent + highlight res.revalidate case (#82479)
- uses invalidate instead of revalidate to make more explicit the revalidatePath, revalidateTag behavior - highlights that eager revalidation can still happen with the pages router method <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
|
0dcee14044 |
docs: add graceful error boundary example (#77781)
This adds an example in the documentation for the errors page for a graceful error boundary in Next.js. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> --------- Co-authored-by: Zack Tanner <[email protected]> Co-authored-by: Delba de Oliveira <[email protected]> |
||
|
|
a556825dd7 |
docs: update React Compiler docs (#78427)
Adds a few clarifications on how the React Compiler side of the world works. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> --------- Co-authored-by: Lee Robinson <[email protected]> |
||
|
|
52284fedb6 |
misc: remove vendored node-fetch usages (#75741)
## What This PR replaces the usage of node-fetch in the next/font/google loader code, which runs as part of every next build. `node-fetch` relies on `punycode`, which shows a deprecration warning from Node.js 22, affecting every users on Next.js and Node 22. This PR also removes any other references to the vendored node-fetch used in other parts of the codebase. ~~Unfortunately, we can't remove it because other next.js dependencies like the amp optimiser actually use node-fetch, so they would need to be updated separately.~~ not a problem anymore because of @wowczarczyk suggestion of also rewriting the external in the dependencies to point to the correct one This PR does not remove the node-fetch usage in tests. ## How This replaces the node-fetch call with a call to the native fetch exposed in Node.js. However, this fetch does not support proxies without tapping into Undici, so I've had to "polyfill" a usage because I did not want to add a dependency to Undici for a minor use case. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- --> Fixes #66289 Fixes #75313 Closes NDX-730 --------- Co-authored-by: JJ Kasper <[email protected]> |
||
|
Jimmy LaiandGitHub
|
a8cdf5774d |
misc: remove authors section in the readme (#75184)
 will follow up with a "meet the team" section on the next.js site <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
a19b9521ad |
misc: update source map paths for bundled Next.js runtime (#71779)
<!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> This changes the generated source map to not do the "webpack://next/dist/<file>" and instead use the relative path. this allows us to use the vanilla ignoreList "node_modules" config to also also ignore those files   |
||
|
Jimmy LaiandGitHub
|
78c9cbe97d |
misc: bump playwright (#71312)
<!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
15aeb92efb | misc: tweak fetch patch restoration timing during HMR to allow for userland fetch patching (#68193) | ||
|
|
73c8d414ed |
misc: add dd-trace to server externals (#68785)
<!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> Unfortunately, dd-trace requires modules in some conditional fashion, as some of our users reported, which is the usual pattern for tracing packages. This PR works around this by marking the package to not be compiled explicitly. Fixes #64419 --------- Co-authored-by: Jiachi Liu <[email protected]> |
||
|
Jimmy LaiandGitHub
|
d52d32f423 |
perf: improve Pages Router server rendering performance (#64461)
### What This PR's goal is to improve the throughput performance of the Next.js server when handling Pages Router routes. Note that the results from this are very synthetic and do not represent the real-life performance of an application. If we only wanted to handle hello worlds, we could probably make this even faster but on production, a slow fetch call to your DB is probably what's slowing you down. I'll look into App Router next. ### Why? I guess I got nerd-sniped into it 😃 ### How? A few optimizations: - I looked deeply at the pipeline for rendering a Pages Router page. I noticed a lot of intermediary streams being created here and there to eventually be concatenated to a simple string. I think this is probably left over code from when we wanted to support streaming there and so there's some code that was shared with the App Router, which we absolutely don't need I think. I refactored it to be slightly simpler with just a few string concats here and there. - misc: I removed some redundant Promises being created here and there and added a small inline optimisation to eliminate `if (renderOpts.dev)` code in production. ### Nummies Test setup: hello world pages router app, next start + autocannon - requests handled in 10s: 18k -> 33K, **~80% improvement** - avg latency: 4.89ms -> 2.8ms, **~42% improvement** - avg req/res: 1846.5 -> 2983.5, **~61% improvement** Before <img width="742" alt="image" src="https://github.com/vercel/next.js/assets/11064311/658e7ade-eba7-4604-a7c9-619bd51a5ec8"> vs after <img width="880" alt="image" src="https://github.com/vercel/next.js/assets/11064311/2f46cf69-b788-4db2-bf90-6f65dc7abd82"> <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> Closes NEXT-3103 |
||
|
Jimmy LaiandGitHub
|
feb27ad621 |
Revert "feat(next/image)!: remove squoosh in favor of sharp as optional dep" (#61810)
Reverts vercel/next.js#61696 Closes NEXT-2401 |
||
|
Jimmy LaiandGitHub
|
883e958271 |
build: remove sentry from the externals list (#61194)
Context: - on app router, we bundle all the code used both on server and client - sentry used to be incompatible with that, however a raw require call on production to Sentry leads to a 350ms impact on cold boots/initial load - it might be ok to bundle now, let's try it out <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> Closes NEXT-2250 |
||
|
|
c52cb5ad83 |
feat(app): add experimental.missingSuspenseWithCSRBailout (#57642)
### What? This PR adds a new flag called `experimental.missingSuspenseWithCSRBailout`. ### Why? Via this PR we can break a build when calling `useSearchParams` without wrapping it in a suspense boundary. If no suspense boundaries are present, Next.js must avoid doing SSR and defer the entire page's rendering to the client. This is not a great default. Instead, we will now break the build so that you are forced to add a boundary. ### How? Add an experimental flag. If a `BailoutToCSRError` error is thrown and this flag is enabled, the build should fail and log an error, instead of showing a warning and bail the entire page to client-side rendering. Closes NEXT-1770 --------- Co-authored-by: Balázs Orbán <[email protected]> Co-authored-by: Wyatt Johnson <[email protected]> |
||
|
Jimmy LaiandGitHub
|
e17b368760 |
misc: delete kodiak (#59082)
We don't need the auto merging from kodiak since Github has one. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> Closes NEXT-1753 |
||
|
Jimmy LaiandGitHub
|
9e33bf6ab9 |
misc: disable automerge (#59077)
Disabling the auto merging behaviour from kodiak. You can queue stuff up by adding an automerge label though. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> Closes NEXT-1751 |
||
|
Jimmy LaiandGitHub
|
8baf2e0b79 |
route handlers: make req.cookies opt you into dynamic (#58769)
This PR fixes an issue where users would try to access `req.cookies` from a route handler and be unable to read from it. This issue was caused by `req.cookies` not opting you into dynamic behaviour, unlike `cookies()` from `next/headers`. This fixes it. |
||
|
Jimmy LaiandGitHub
|
4024b25e8c |
parallel routes: fix catch all route support (#58215)
This PR fixes a bug where parallel routes would not apply appropriately on navigation when used within slots.
The following scenarios:
```
/foo
/bar
/@slot
/[...catchAll]
```
or
```
/foo
/[...catchAll]
/@slot
/bar
```
will now function correctly when accessing /foo/bar, and Next.js will render both /bar and the catchall slots.
The issue was that the tree constructed by `next-app-loader` for a given path, /foo/bar in the example, would not include the paths for the catch-all files at build time. The routing was done 1-1 when compiling files, where a path would only match one file, with parallel routes, a path could hit a defined path but also a catch all route at the same time in a different slot.
The fix consists of adding another normalisation layer that will look for all catch-all in `appPaths` and iterate over the other paths and add the relevant information when needed.
The tricky part was making sure that we only included the relevant paths to the loader: we don't want to overwrite a slot with a catch all if there's already a more specific subpath in that slot, i.e. if there's /foo/@slot/bar/page.js, no need to inject /foo/@slot/bar/[...catchAll].
One thing that is not supported right now is optional catch all routes, will add later.
fixes #48719
fixes #49662
|
||
|
Jimmy LaiandGitHub
|
536d2dbc44 |
interception routes: fix interception for dynamic routes (#58198)
This PR fixes the bug in which interception routes of the form `(.)[param]` would not intercept navigations. The bug happened because we would not create a dynamic route matcher for the intercepted route, so we would never match the correct dynamic route when hitting the server, falling back to the base one. The fix consists of fixing the logic that checks for a dynamic route so that it checks the correct path when handling an interception route. There's probably a better fix here, advice welcome fixes #52533 |
||
|
Jimmy LaiandGitHub
|
82d1b57721 |
misc: fix serverComponentsExternalPackages usage for experimental.bundlePagesExternals (#57954)
This PR fixes a bug where Next.js would not use the serverComponentsExternalPackages config when opting into the `experimental.bundlePagesExternals` flag. The fix consists of just adding a check for the externals config. |
||
|
Jimmy LaiandGitHub
|
e3e95b30e5 |
chore: update otel (#57774)
bumping the vendored otel package |
||
|
Jimmy LaiandGitHub
|
6e6503f59e |
perf: change the chunks configuration for server code (#57773)
Stumbled upon this while investigating. The previous configuration did not make a lot of sense. On Node, fs reads can be expensive so it's best to avoid them as much as possible. The current configuration would create chunks eagerly for nothing, leading to sub optimal perf. The only reason we want chunk on the server is to avoid reloading common parts between entrypoints, so I'm changing the config to reflect that. |
||
|
Jimmy Lai
|
0bcba460b7 | fix publish script | ||
|
Jimmy LaiandGitHub
|
cfbffb2ff4 |
Revert "Apply react-server transform and valication to middleware (#5… (#57504)
…7448)"
This reverts commit
|
||
|
Jimmy LaiandGitHub
|
3e7f96e16a |
revert "Apply react-server condition for pages api (#57459)" (#57500)
This reverts commit
|
||
|
|
907f37978e |
perf: enable webpack build worker (#57346)
This PR enables the `experimental.webpackBuildWorker` to be on by default. This flag enables logic inside Next.js to run the compilation in an isolated worker. The reason for this is that the webpack compilation process retains a lot of memory for the whole duration of the build process because it uses some packages that leak. We don't need it for the rest of the process so it's best to use it in a worker and leave the memory to be used for static generation. This will improve memory usage during build, avoiding OOMs caused by webpack exceeding memory. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> --------- Co-authored-by: JJ Kasper <[email protected]> |
||
|
Jimmy LaiandGitHub
|
b118ffd154 |
misc: fix build output (#57466)
mark dynamic routes as always dynamic <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
6b6eddb50e |
misc: fix unhandled err worker hook (#57465)
<!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
da6562e4a1 |
misc: build output rework (#57440)
This PR updates the build output in order to reflect the changes brought by PPR and also to make it more consistent. before ``` ○ (Static) automatically pre-rendered as static HTML ◐ (Partially Pre-Rendered) static parts of the page were pre-rendered and the dynamic parts will be streamed ℇ (Streaming) server-side renders with streaming (uses React 18 SSR streaming or Server Components) λ (Server) server-side renders at runtime (uses getInitialProps or getServerSideProps) ``` after ``` ○ (Static) prerendered as static HTML ◐ (Partial Prerender) prerendered as static HTML with dynamic server-streamed content λ (Dynamic) server-rendered on demand using Node.js ℇ (Edge Runtime) server-rendered on demand using the Edge Runtime ``` <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
1d185c0707 |
perf: avoid using raw-body for server actions (#57358)
This PR removes the usage of `raw-body` for App Router pages by parsing the body for an action ourselves whilst assuming that it is encoded with UTF-8. This is already what we do for the Edge Runtime version of Server Actions and will only break if your page overrides the page encoding, which should not happen and that we don't need to support. This should remove a third of a serverless function zip size <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
cb5d075758 |
misc: fix bundling of experimental (#57311)
this removes the call to experimental static react when not using the experimental build |
||
|
|
ce085b56dd |
revert "React Aliases (#57283)" (#57299)
This reverts commit
|
||
|
Jimmy LaiandGitHub
|
9e050fba94 |
perf: remove parse-body from the server runtime (#57280)
This PR removes the `raw-body` dependency from the server runtime. It still is used in the pages runtime but at least if you're only using app, you won't bundle your server function with it. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
7208535786 |
perf: fix memory leaks in the edge runtime in dev (#57235)
This PR fixes a memory leak when using `next dev` where on HMR, we would always retain the memory associated with the old VM instance, leading to pretty egregious usage of RAM after only a few edits. The leak itself comes from methods like `setTimeout` and `setInterval` capturing the context in which they were called and somehow never releasing, even if the timeout happened, when running in a Node.js `vm`. This is probably a Node.js bug. The fix consists of taking ownership of all timeouts and clearing them ourselves manually at the end of each VM lifecycle. Tested manually: - hello world Next.js app with edge runtime - triggered hmr 10 times - memory usage - base: 400MB - before: 800MB - after: 400MB |
||
|
Jimmy LaiandGitHub
|
1836998e52 |
perf: memory usage tweaks (#57163)
This PR does two things: - bring back the logic to restart the dev server when approaching 80% of the heap limits - add some logic to increase the default Node.js memory usage to 50% of the available RAM Tested manually <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
4e27b908fe |
misc: fix injecting --inspect with NODE_OPTIONS (#57159)
This PR fixes the passing of the `--inspect` option when calling Next.js with it. It's still not great because you need to target the next file in node_modules directly but I'll add a `next --inspect` option in the future. |
||
|
Jimmy LaiandGitHub
|
6d2df8636a |
build: don't error when bundling optional peer deps (#57073)
This PR adds a resolver plugin to verify during bundling that when a module is unresolved, that it is not an optional peer dependency specified in the package.json of the caller. An error would happen if you try to bundle packages like `typeorm` since there are `require` calls in the code to those dependencies. Also, swallow dynamic dependencies warnings in `require` calls error if they come from `node_modules`. They are not actionable at all generally. |
||
|
Jimmy LaiandGitHub
|
451a54cb2e |
cache: add unstable_noStore API (#56930)
This PR introduces a new API, `unstable_noStore`, which will allow users to declaratively opt out of caching anywhere during static generation in the same way that you can specify `cache: 'no-store'` on a fetch call in Next.js.
An important caveat and difference from just calling `cookies()` to opt-out of static generation is that this won't opt you out when called from within `unstable_cache` and instead defers to the cache configuration to it.
```
import {unstable_noStore as noStore} from 'next/cache';
export default async function Component() {
noStore();
const result = await db.query(...);
}
```
|
||
|
Jimmy LaiandGitHub
|
552b9747ff |
perf: fix tracing for routes (#56924)
follow up to #56898 where I noticed that we don't apply any filtering to the trace files for the user routes, resulting in files that would need to be filtered like `caniuse` not being filtered out correctly. This fixes that. A lambda in my test project goes from `2.7MB` to `1.4MB` followup: add some snapshot tests before ``` Serverless function size info Serverless Function's pages: _not-found.js, index.js Large Dependencies Uncompressed size Compressed size node_modules/.pnpm/[email protected][email protected][email protected] 4.61 MB 1.35 MB node_modules/.pnpm/[email protected] 909.73 KB 327.14 KB node_modules/.pnpm/[email protected][email protected] 546.21 KB 138.87 KB All dependencies 3.66 MB 2.01 MB Serverless Function's page: favicon.ico.js Large Dependencies Uncompressed size Compressed size node_modules/.pnpm/[email protected][email protected][email protected] 6.71 MB 2.05 MB node_modules/.pnpm/[email protected] 909.73 KB 327.14 KB node_modules/.pnpm/[email protected][email protected] 546.21 KB 138.87 KB All dependencies 5.78 MB 2.71 MB Serverless Function's page: api/hello-world.js Large Dependencies Uncompressed size Compressed size node_modules/.pnpm/[email protected][email protected][email protected] 4.61 MB 1.35 MB node_modules/.pnpm/[email protected] 909.73 KB 327.14 KB node_modules/.pnpm/[email protected][email protected] 546.21 KB 138.87 KB All dependencies 3.65 MB 2.01 MB ``` after ``` Large Dependencies Uncompressed size Compressed size node_modules/.pnpm/[email protected][email protected] 2.87 MB 844.1 KB All dependencies 341.31 KB 992.45 KB Serverless Function's page: favicon.ico.js Large Dependencies Uncompressed size Compressed size node_modules/.pnpm/[email protected][email protected] 4.97 MB 1.52 MB All dependencies 2.45 MB 1.67 MB Serverless Function's page: api/hello-world.js Large Dependencies Uncompressed size Compressed size node_modules/.pnpm/[email protected][email protected] 2.87 MB 844.1 KB All dependencies 328.64 KB 989.23 KB ```` |
||
|
Jimmy LaiandGitHub
|
9fda481af1 | perf: fix server trace file logic (#56898) | ||
|
Jimmy LaiandGitHub
|
62ab0e33a2 |
ci: add job summary to the test suite runs (#56742)
This PR adds Github Actions summaries to the test suite that runs in the CI so that you can easily visualise which tests failed + what the relevant log was instead of parsing the logs yourself. Example here https://github.com/vercel/next.js/actions/runs/6495658699  |
||
|
Jimmy LaiandGitHub
|
ebebb6a96a |
CI: add manual workflow for running e2e on prod (#56738)
This PR adds a job to the `build-and-deploy` workflow so that we run e2e tests on production/vercel if the job was dispatched manually. This is useful if you need to double-check your PR since we don't run them on production for every PRs. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
35a99232c0 |
misc: tweak stats github action (#56694)
This PR adds a few tweaks to our Github actions PR: - expand by default the main section - add some heuristics to not show hash/id changes in the diff view - add some heuristics to not show increase/decrease size when it's too small (100 bytes is noise most often) - add rendering runtimes to the list of tracked files after vs before   |
||
|
Jimmy LaiandGitHub
|
d4fcd03966 |
misc: split app-render into smaller functions (#56611)
This PR splits apart the function used to render App Router pages into smaller chunks for better readability + testing. A lot of the complexity is tied by the fact that a lot of the code of the function relied on closures so I had to coalesce a lot of the captured variables used into one big context that is then passed around during render. There are a lot of things to slim down further but I don't have the energy to dig more. |
||
|
Jimmy LaiandGitHub
|
56fe014532 |
chore: bump pnpm to 8.9 (#56649)
There's allegedly a bump in performance for mac for pnpm 8.9 so upgrading it in the repo. |
||
|
Jimmy LaiandGitHub
|
c4c60b37f7 |
misc: force run e2e deploy tests with bundled server (#56513)
This PR forces the deployments used for e2e testing to use the bundled server. Manual deploy run https://github.com/vercel/next.js/actions/runs/6430048350 |
||
|
Jimmy LaiandGitHub
|
bc15b5803c |
misc: fix wrong next start start duration (#56512)
This PR fixes `next start` and `next dev` so that they show the correct server boot-up time. The previous way of computing the start time was incorrect and misleading as it did not start exactly when next started. Before: > ✓ Ready in 120ms After: > ✓ Ready in 286ms |
||
|
Jimmy LaiandGitHub
|
5fbc23e7b2 |
misc: fix instrumentation with bundled server (#56318)
This PR fixes an issue with the instrumentation hook breaking with the bundled server. I'll follow up with a better test setup for the bundled server in a follow up (tomorrow). <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
dba978f4ba |
misc: shortcut styled-jsx in external resolution (#56291)
This PR just shortcuts the styled-jsx resolution to tell webpack to compile it immediately. I noticed this could cause an issue if `config.experimental.bundlePagesExternals` was enabled. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
458dab83ca |
misc: update code owners (#56290)
Adding myself to the build folder config <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
ecd94c1a4d |
misc: enable source maps for bundled runtime (#56289)
This PR enables the generation of source maps for the bundled runtimes. This is fast enough that we can just use the optimal source map option directly. This is useful if you're having some errors in Next.js itself. |
||
|
Jimmy LaiandGitHub
|
8f0f8236ab |
perf: add option to bundle pages externals (#56162)
This PR adds an option to forcefully bundle node_modules packages in `pages` on the server. This should benefit cold boots for projects that uses pages, at the cost of build time increase. |
||
|
Jimmy LaiandGitHub
|
57bd3232f6 |
misc: refactor handleExternals (#56161)
This PR just moves handleExternal off the main webpack config file for better readability. |
||
|
Jimmy LaiandGitHub
|
3e32378c73 |
misc: refactor node utils (#56096)
This PR just splits apart a big file. Not a big size improvement but still worthwhile. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
e9c264db56 |
perf: externalise ws for bundled server (#56095)
This PR makes `ws` an external. AFAIK we don't really need it on prod, so this saves around 40KB on the server. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
c2fd08063c |
perf: replace zod with superstruct (#56083)
This PR replaces the usage of Zod in the App Router in favour of a smaller validation library. We don't use much of zod's more advanced capabilities so it doesn't make sense to import all of it on the server at the moment. Also added some unit tests. This results in a 44kb win, which will impact cold boot Before: <img width="594" alt="CleanShot 2023-09-27 at 13 34 09@2x" src="https://github.com/vercel/next.js/assets/11064311/43cc7687-947d-40a1-9e1e-c2a60caf53c0"> After: <img width="564" alt="CleanShot 2023-09-27 at 13 34 48@2x" src="https://github.com/vercel/next.js/assets/11064311/c3d3f5d6-e1f6-4969-bd11-dcd191d34ce6"> <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
3b0ee4e5f8 |
perf: remove react dom legacy from app router (#56082)
This PR includes changes to Next.js bundling in order to aliases references to the `react-dom/server` legacy build to a no-op in order to save KBs. We don't use any of the legacy methods so it's best to just shave it off. This should improve cold boots for both edge and regular servers. Before: <img width="622" alt="CleanShot 2023-09-27 at 13 30 47@2x" src="https://github.com/vercel/next.js/assets/11064311/fa383000-c71e-420e-9daa-b8d93ff242e7"> After: <img width="622" alt="CleanShot 2023-09-27 at 13 31 32@2x" src="https://github.com/vercel/next.js/assets/11064311/702f083a-705f-4b12-9133-9bb7eb02109e"> A win of 70KBs. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
341b67859d |
misc: stop hiding node_modules in vscode (#56081)
I find myself digging a lot through node_modules so I'd rather have it displayed in VSCode. |
||
|
Jimmy LaiandGitHub
|
8372bd13e6 |
misc: add node-version file (#55938)
Adding a node-version file to be used by fnm/nvm. Currently, the version chosen is the one specified in package.json aka node 16. We're soon deprecating 16 so let's use 18 in development. |
||
|
Jimmy LaiandGitHub
|
ca57258dbd |
app router: ensure static prefetch renders loading.js (#55950)
Should fix the problem surfaced in https://github.com/vercel/next.js/issues/43548#issuecomment-1732416492 The scenario in which this breaks is when we're asking the app renderer to generate a prefetch payload statically. The renderer was not checking if there were loading.js below the current rendering level, which is the root when statically rendering, so it would always render null, which was incorrect. Tested out with the original repro https://next-instant-loading-8nv6psqod-feedthejim.vercel.app |
||
|
Jimmy LaiandGitHub
|
76c9b2c469 |
misc: improve profiling script (#55732)
This PR improves the minimal server script by adding a slightly better look require profiler + some misc utility changes. This is eventually gonna be the basis for a `next profile` command. This is what the output look like + its usage. https://app.warp.dev/block/4AtutJ2PpVcM5BFDqlk7zk ``` next-cold-start: 56.024ms next-request: 58.462ms next-wall-time: 128.757ms └─ ../../../packages/next/dist/compiled/next-server/server.runtime.prod.js 39.31ms / 49.27ms ├─ ../../../server/lib/trace/tracer.js 9.92ms / 20.97ms │ ├─ ../constants.js 0.19ms / 0.19ms │ └─ ../../../../../../../node_modules/.pnpm/@[email protected]/node_modules/@opentelemetry/api/build/src/index.js 10.86ms / 18.94ms │ ├─ ../baggage/utils.js 4.35ms / 7.41ms │ │ ├─ ../../api/diag.js 2.98ms / 5.70ms │ │ │ ├─ ../../diag/ComponentLogger.js 2.02ms / 3.66ms │ │ │ │ └─ ../../internal/global-utils.js 1.65ms / 2.71ms │ │ │ │ ├─ ../../platform/index.js 0.90ms / 1.22ms │ │ │ │ │ └─ ../node/index.js 0.32ms / 0.35ms │ │ │ │ │ └─ ../globalThis.js 0.03ms / 0.03ms │ │ │ │ ├─ ../../version.js 0.02ms / 0.02ms │ │ │ │ └─ ../semver.js 0.14ms / 0.14ms │ │ │ └─ ../../diag/internal/logLevelLogger.js 0.70ms / 0.76ms │ │ │ └─ ../../types.js 0.06ms / 0.06ms │ │ ├─ ../internal/baggage-impl.js 0.06ms / 0.06ms │ │ └─ ../internal/symbol.js 0.03ms / 0.03ms │ ├─ ../context/context.js 0.06ms / 0.06ms │ ├─ ../diag/consoleLogger.js 0.04ms / 0.04ms │ ├─ ../metrics/NoopMeter.js 0.12ms / 0.12ms │ ├─ ../metrics/Metric.js 0.03ms / 0.03ms │ ├─ ../propagation/TextMapPropagator.js 0.03ms / 0.03ms │ ├─ ../trace/ProxyTracer.js 1.69ms / 3.11ms │ │ └─ ../NoopTracer.js 1.42ms / 2.82ms │ │ ├─ ../../api/context.js 0.66ms / 0.73ms │ │ │ └─ ../../context/NoopContextManager.js 0.07ms / 0.07ms │ │ ├─ ../context-utils.js 0.70ms / 0.90ms │ │ │ └─ ../NonRecordingSpan.js 0.21ms / 0.55ms │ │ │ └─ ../invalid-span-constants.js 0.34ms / 0.37ms │ │ │ └─ ../trace_flags.js 0.03ms / 0.03ms │ │ └─ ../spancontext-utils.js 0.04ms / 0.04ms │ ├─ ../trace/ProxyTracerProvider.js 0.30ms / 0.33ms │ │ └─ ../NoopTracerProvider.js 0.03ms / 0.03ms │ ├─ ../trace/SamplingResult.js 0.03ms / 0.03ms │ ├─ ../trace/span_kind.js 0.03ms / 0.03ms │ ├─ ../trace/status.js 0.03ms / 0.03ms │ ├─ ../trace/internal/utils.js 0.44ms / 0.64ms │ │ └─ ../tracestate-impl.js 0.20ms / 0.25ms │ │ └─ ../tracestate-validators.js 0.04ms / 0.04ms │ ├─ ../context-api.js 0.06ms / 0.06ms │ ├─ ../diag-api.js 0.04ms / 0.04ms │ ├─ ../metrics-api.js 0.22ms / 0.48ms │ │ └─ ../api/metrics.js 0.26ms / 0.32ms │ │ └─ ../../metrics/NoopMeterProvider.js 0.06ms / 0.06ms │ ├─ ../propagation-api.js 0.30ms / 0.92ms │ │ └─ ../api/propagation.js 0.62ms / 0.74ms │ │ ├─ ../../propagation/NoopTextMapPropagator.js 0.03ms / 0.03ms │ │ └─ ../../baggage/context-helpers.js 0.09ms / 0.09ms │ └─ ../trace-api.js 0.31ms / 0.45ms │ └─ ../api/trace.js 0.15ms / 0.15ms ├─ ../../../shared/lib/runtime-config.external.js 0.05ms / 0.05ms ├─ ../../../../../../bench/basic-app/.next/server/app/page.js 4.07ms / 18.76ms │ ├─ ../../webpack-runtime.js 0.10ms / 0.10ms │ ├─ ../../chunks/388.js 0.06ms / 0.06ms │ ├─ ../../chunks/269.js 1.10ms / 1.10ms │ ├─ ../../../../../../packages/next/dist/compiled/next-server/app-page.runtime.prod.js 13.22ms / 13.63ms │ │ └─ ../../../client/components/request-async-storage.external.js 0.41ms / 0.47ms │ │ └─ ../async-local-storage.js 0.06ms / 0.06ms │ ├─ ../../../../../../packages/next/dist/client/components/static-generation-async-storage.external.js 0.16ms / 0.16ms │ └─ ../../../../../../packages/next/dist/client/components/action-async-storage.external.js 0.05ms / 0.05ms └─ ../../../../../../bench/basic-app/.next/server/app/page_client-reference-manifest.js 0.11ms / 0.11ms ``` |
||
|
Jimmy LaiandGitHub
|
aa4efc11d9 |
build: add aliases for react-dom/server usage in server bundles (#55536)
Some people are using `ReactDOM/server` in some contexts like App Routes and Server Actions. The changes in #55362 made it so that there were no more aliases if they wanted to use it so it would fallback to their versions of React, which might not include the APIs you would expect from canary. Also reverting the decision to proxy `ReactDOM/server` to `ReactDOM/server.edge` in the SSR layer as the APIs are not the same. |
||
|
|
bd705537a3 |
server: bundle vendored react (#55362)
## What This PR changes Next.js to bundle its vendored React libraries so that the App Router pages can use those built-in versions. ## Why Next.js supports both Pages and App Router and we've gone through a lot of iteration to make sure that Next.js stays flexible wrt to the version of React used: in Pages, we want to use the React provided by the user and in the App Router, to be able to use it, we need to use the canary version of React, which we've built into Next.js for convenience. The problem stems from the fact that you can't run two different instances of React (by design). Previously we have a dual worker setup, where we would separate completely each Next.js versions (App and Pages) so that they would not overlap with each other, however this approach was not great performance and memory wise. We've recently tried using an ESM loader and a single process, but this change would still opt you into the React canary version if you had an app page, which breaks some assumptions. ## How A list of the changes in this PR: ### New versions of the Next.js runtime Since we now compile a runtime per type of page (app/route/api/pages), in order to bundle the two versions of React that we vendored, we introduced a new type of bundle suffixed by `-experimental`. This bundle will have the bleeding edge React needed for Server Actions and Next.js will opt you in into that runtime automatically. For internal contributors, it means that we now run a compiler for 10 subparts of Next.js: - next_bundle_server - next_bundle_pages_prod - next_bundle_pages_turbo - next_bundle_pages_dev - next_bundle_app_turbo_experimental - next_bundle_app_prod - next_bundle_app_prod_experimental - next_bundle_app_turbo - next_bundle_app_dev_experimental - next_bundle_app_dev  ### Simplified require-hook Since the versions of React are correctly re-routed at build time for app pages, we don't need the require hook anymore ### Turbopack changes The bundling logic in Turbopack has been addressed to properly follow the new logic ### Changes to the shared contexts system Some context files need to have a shared instance between the rendering runtime and the user code, like the one that powers the `next/image` component. In general, the aliasing setup takes care of that but we need the require hook for code that is not compiled to reroute to the correct runtime. This only happens for pages node_modules. A new Turbopack resolving plugin has been added to handle that logic in Turbopack. ### Misc changes - `runtime-config` (that powers `next/config`) has been converted to an `.external` file, as it should have been - there are some rules that have been added to the aliases to support the usage of `react-dom/server` in a server-components. We can do that now since the runtime takes care of separating the versions of React. Co-authored-by: JJ Kasper <[email protected]> |
||
|
Jimmy LaiandGitHub
|
b784d819d8 |
server: switch pages to react dom edge renderer (#55318)
This PR fixes the warnings that have started to appear because of #54813 ``` Warning: Detected multiple renderers concurrently rendering the same context provider. This is currently unsupported. at PathnameContextProviderAdapter (/Users/feedthejim/Projects/vercel/next.js/packages/next/dist/shared/lib/router/adapters.shared-runtime.js:84:11) at Be (/Users/feedthejim/Projects/vercel/next.js/packages/next/dist/compiled/next-server/pages.runtime.dev.js:1:47625) at Ze (/Users/feedthejim/Projects/vercel/next.js/packages/next/dist/compiled/next-server/pages.runtime.dev.js:1:48314) at div at Ye (/Users/feedthejim/Projects/vercel/next.js/packages/next/dist/compiled/next-server/pages.runtime.dev.js:1:55388) Warning: Detected multiple renderers concurrently rendering the same context provider. This is currently unsupported. at PathnameContextProviderAdapter (/Users/feedthejim/Projects/vercel/next.js/packages/next/dist/shared/lib/router/adapters.shared-runtime.js:84:11) at Be (/Users/feedthejim/Projects/vercel/next.js/packages/next/dist/compiled/next-server/pages.runtime.dev.js:1:47625) at Ze (/Users/feedthejim/Projects/vercel/next.js/packages/next/dist/compiled/next-server/pages.runtime.dev.js:1:48314) at div at Ye (/Users/feedthejim/Projects/vercel/next.js/packages/next/dist/compiled/next-server/pages.runtime.dev.js:1:55388) ``` they appear because we are using two variants versions of `react-dom` on the server between pages and app router. This changes so that we only use one when you use app and as such, makes the warning disappear. |
||
|
Jimmy LaiandGitHub
|
2a7f5cdb0a |
build: fix minimal trace caching (#55279)
This PR fixes a small issue where we would not save nor read the minimal server trace file from the cache, meaning that whenever you would do two builds in a row, the build would skip the tracing of the server as expected but not include a minimal server trace in the dist folder. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
||
|
Jimmy LaiandGitHub
|
f4e6dea1f2 |
build: fix externals resolution when importing from next/dist (#55269)
This fixes a "bug" where Sentry was trying to access some of the internal async storages and it would fail because their imports would be compiled as-is instead of using the special rules for Next externals as we are short-cutting it for `next/dist` requests for some reason. Not a bug per se because this is technically an undocumented API but I think it's a reasonable fix since we don't provide an API for that. The alternative for them would be to try to play around with the bundling, which is not a good use of anyone's time. |
||
|
Jimmy LaiandGitHub
|
df76f6633f |
server: remove turbopack-specific code when compiling with webpack (#55226)
This PR tweaks the webpack config so that when we compile user code with webpack, we remove all branches of code that are guarded with `process.env.TURBOPACK`. I noticed that the bundle runtime was not tree-shaken correctly, this fixes that. |
||
|
|
6e5b935fd7 |
server: require hook hotfix (#55146)
This PR fixes a bug in the require hook implementation where the variable used might not exist depending on the environment. In order to fix that, we can use the variable used to define the version of React used instead as it is already present and a proxy of the same information. Co-authored-by: JJ Kasper <[email protected]> |
||
|
|
5217e7eb06 |
server: re-land bundled runtimes (#55139)
see https://github.com/vercel/next.js/pull/52997 also added a fix by @jridgewell to fix turbopack Co-authored-by: Justin Ridgewell <[email protected]> |
||
|
|
a5b7c77c1f |
perf: add bundled rendering runtimes (#52997)
## What? In Next, rendering a route involves 3 layers: - the routing layer, which will direct the request to the correct route to render - the rendering layer, which will take a route and render it appropriately - the user layer, which contains the user code In #51831, in order to optimise the boot time of Next.js, I introduced a change that allowed the routing layer to be bundled. In this PR, I'm doing the same for the rendering layer. This is building up on @wyattjoh's work that initially split the routing and the rendering layer into separate entry-points. The benefits of having this approach is that this allows us to compartmentalise the different part of Next, optimise them individually and making sure that serving a request is as efficient as possible, e.g. rendering a `pages` route should not need code from the `app router` to be used. There are now 4 different rendering runtimes, depending on the route type: - app pages: for App Router pages - app routes: for App Router route handlers - pages: for legacy pages - pages api: for legacy API routes This change should be transparent to the end user, beside faster cold boots. ## Notable changes Doing this change required a lot of changes for Next.js under the hood in order to make the different layers play well together. ### New conventions for externals/shared modules The big issue of bundling the rendering runtimes is that the user code needs to be able to reference an instance of a module/value created in Next during the render. This is the case when the user wants to access the router context during SSR via `next/link` for example; when you call `useContext(value)` the value needs to be the exact same reference to one as the one created by `createContext` earlier. Previously, we were handling this case by making all files from Next that were affected by this `externals`, meaning that we were marking them not to be bundled. **Why not keep it this way?** The goal of this PR as stated previously was to make the rendering process as efficient as possible, so I really wanted to avoid extraneous fs reads to unoptimised code. In order to "fix" it, I introduced two new conventions to the codebase: - all files that explicitly need to be shared between a rendering runtime and the user code must be suffixed by `.shared-runtime` and exposed via adding a reference in the relevant `externals` file. At compilation time, a reference to a file ending with this will get re-written to the appropriate runtime. - all files that need to be truly externals need to be suffixed by `.external`. At compilation time, a reference to it will stay as-is. This special case is needed mostly only for the async local storages that need to be shared with all three layers of Next. As a side effect, we should be bundling more of the Next code in the user bundles, so it should be slightly more efficient. ### App route handlers are compiled on their own layer App route handlers should be compiled in their own layer, this allows us to separate more cleanly the compilation logic here (we don't need to run the RSC logic for example). ### New rendering bundles We now generate a prod and a dev bundle for: - the routing server - the app/pages SSR rendering process - the API routes process The development bundle is needed because: - there is code in Next that relies on NODE_ENV - because we opt out of the logic referencing the correct rendering runtime in dev for a `shared-runtime` file. This is because we don't need to and that Turbopack does not support rewriting an external to something that looks like this `require('foo').bar.baz` yet. We will need to fix that when Turbopack build ships. ### New development pipeline Bundling Next is now required when developing on the repo so I extended the taskfile setup to account for that. The webpack config for Next itself lives in `webpack.config.js` and contains the logic for all the new bundles generated. ### Misc changes There are some misc reshuffling in the code to better use the tree shaking abilities that we can now use. fixes NEXT-1573 Co-authored-by: Alex Kirszenberg <[email protected]> |
||
|
Jimmy LaiandGitHub
|
5471cd930c |
webpack: tweak config for split chunks (#55054)
Slight tweaks to the dev config for split chunks. I disabled the default groups for chunking to make sure we only chunked the ones from the node_modules + augmented the number of parallel requests possible per Tobias suggestion. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> |
