chore: bump next.js from 16.2.7 to 16.3.0 - #17633
Merged
Merged
Conversation
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Contributor
📦 esbuild Bundle Analysis for payloadThis analysis was generated by esbuild-bundle-analyzer. 🤖
Largest pathsThese visualization shows top 20 largest paths in the bundle.Meta file: packages/next/meta_index.json, Out file: esbuild/index.js
Meta file: packages/payload/meta_index.json, Out file: esbuild/index.js
Meta file: packages/payload/meta_shared.json, Out file: esbuild/exports/shared.js
Meta file: packages/richtext-lexical/meta_client.json, Out file: esbuild/exports/client_optimized/index.js
Meta file: packages/ui/meta_client.json, Out file: esbuild/exports/client_optimized/index.js
Meta file: packages/ui/meta_shared.json, Out file: esbuild/exports/shared_optimized/index.js
DetailsNext to the size is how much the size has increased or decreased compared with the base branch of this PR.
|
AlessioGr
previously approved these changes
Aug 4, 2026
nathanlentz
disabled the stack merge
August 4, 2026 20:27
nathanlentz
disabled the stack merge
August 4, 2026 20:29
nathanlentz
force-pushed
the
chore/next-16-3-bump
branch
from
August 4, 2026 20:29
41e7926 to
226565b
Compare
denolfe
previously approved these changes
Aug 4, 2026
Bumps the Next.js version used in the monorepo, along with the pinned @next/env and @next/eslint-plugin-next packages. Next.js 16.3 changes the default of experimental.useTypeScriptCli to true, which makes Next look for a `typescript/bin/tsc` binary instead of the compiler API. This repo aliases `typescript` to @typescript/typescript6, which only ships a `tsc6` bin, so Next reported TypeScript as missing and tried to install it at the workspace root. Both next.config.mjs files now set the flag to false so Next keeps using the compiler API. Templates stay on 16.2.7 and are bumped separately.
Nesting @Keyframes inside a style rule is invalid CSS - only conditional group rules can nest. Next.js 16.3 ships a stricter CSS parser that rejects the rule and drops the read-only editor styles. Hoist the keyframes to the top level of the layer and scope its name, since hoisting makes the name global.
The canary line renamed the HMR path at 16.2.1-canary.2, a month before 16.3.0-canary.0 existed, while the 16.2 patches were cut from a branch without the rename. So 16.2.1-canary.26 serves /_next/hmr and 16.2.7 serves /_next/webpack-hmr. The 16.3 boundary holds for stable releases only.
nathanlentz
force-pushed
the
chore/next-16-3-bump
branch
from
August 4, 2026 21:10
226565b to
68eb761
Compare
AlessioGr
approved these changes
Aug 4, 2026
nathanlentz
added a commit
that referenced
this pull request
Aug 5, 2026
) Backport of #17632 and #17633 to `3.x`. ### What? Payload's config hot reload in development stopped working on Next.js 16.3. Adding a collection or a field had no effect until the dev server was restarted. Next.js 16.3 renamed the dev HMR WebSocket endpoint: - Old: `/_next/webpack-hmr` — [`router-server.ts#L859-L860` on `v16.2.7`](https://github.com/vercel/next.js/blob/v16.2.7/packages/next/src/server/lib/router-server.ts#L859-L860) - New: `/_next/hmr` — [`router-server.ts#L946-L947` on `v16.3.0`](https://github.com/vercel/next.js/blob/v16.3.0/packages/next/src/server/lib/router-server.ts#L946-L947) The client moved with it, in [`client/dev/hot-reloader/app/web-socket.ts`](https://github.com/vercel/next.js/blob/v16.3.0/packages/next/src/client/dev/hot-reloader/app/web-socket.ts). There is no alias in either direction: `/_next/webpack-hmr` appears only in old docs inside the 16.3.0 build, and `/_next/hmr` does not appear anywhere in 16.2.7. This branch also bumps the monorepo to Next.js 16.3.0. `3.x` was on a mix of `16.2.3` (root) and `16.2.6` (`test/`, `packages/next`). ### Why? Payload hardcoded `/_next/webpack-hmr`. On 16.3 the upgrade request no longer matched, so the socket never opened. The failure was invisible because the `onerror` handler and the surrounding `try` block both swallow errors, so `cached.reload` stayed `false` and the reload never ran. No type regeneration, no import map regeneration, and no client config cache clear. [Related Vercel PR](vercel/next.js#91415), which went into canary several months ago. ### How? Read the installed Next.js version and connect to the path that version serves: `/_next/hmr` at 16.3 and above, `/_next/webpack-hmr` below it. One socket, no configuration, correct across supported Next.js versions. ``` /_next/hmr => open /_next/webpack-hmr => no response after 8s /_next/not-a-real-path => no response after 8s ``` A wrong path never errors and never closes, so a fallback triggered by failure would hang forever on Next 16.2 and below and break HMR for every older version. `PAYLOAD_HMR_URL_OVERRIDE` keeps working and is still used verbatim, skipping version detection. ### Differences from the changes on `main` - `main` extracted a `defaultNextJsDevReloadStrategy` into `nextJsDevReloadStrategy.ts`. `3.x` has no `DevReloadStrategy` abstraction, so only the URL selection is extracted, as `getNextJsHMRURL.ts`. The socket handling stays inline in `getPayload`. - `main` sets `experimental.useTypeScriptCli: false` in both `next.config.mjs` files, because it aliases `typescript` to `@typescript/typescript6`, which ships no `tsc` bin for Next 16.3's new CLI mode to find. `3.x` uses plain `typescript@5.7.3`, so the alias problem does not exist and the setting is not needed. - `main` added `minimumReleaseAgeExclude` entries to `pnpm-workspace.yaml`. `3.x` does not set `minimumReleaseAge`. - `packages/payload` keeps `@next/env` at `^15.1.5` rather than pinning `16.3.0`, since that range also serves apps on Next 15. - Templates are unchanged, as on `main` (coming in later PR)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps the Next.js version used in the monorepo from
16.2.7to16.3.0, along with the pinned@next/envand@next/eslint-plugin-nextpackages.Stacked on #17632 — review that one first.
TypeScript detection
Next.js 16.3 changes the default of
experimental.useTypeScriptClitotrue. In CLI mode Next looks for atypescript/bin/tscbinary instead of the compiler API attypescript/lib/typescript.js:This repo aliases
typescriptto@typescript/typescript6, which only ships atsc6bin.getTypeScriptPackageInforeadspackageJson.bin.tsc, getsundefined, and Next reports the package as missing — then tries to runpnpm add --save-dev typescriptat the workspace root, which fails:Both
next.config.mjsandtest/next.config.mjsnow setuseTypeScriptCli: falseso Next keeps using the compiler API, which the alias does provide.Scope
Templates stay on
16.2.7and are bumped separately, to keep this diff reviewable.Testing
@next/envresolves at16.3.0from bothpackages/payloadandtest;@next/eslint-plugin-nextresolves at16.3.0frompackages/next.