[pull] canary from vercel:canary #122

supersedes #51783 ## What This PR fixes the issue of `<a>` tags for internal routing not being caught by linting in the app directory. ## Why The linting of the html links should be consistent across pages and app directories. ## How - Added a new function to parse the URLs in the appDir (since it's a bit different from the /pages directory) - Lint now checks against pagesUrls and appUrls - Added tests for the appDir in the no-html-link-for-pages test file fixes #51742 --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>

params from `{}` to `{ slug: undefined }`. Fixes #70124

…0180) Updates the docs to add a note about running `tsc` yourself. If you're ignoring Typescript errors during build time you should probably run `tsc` yourself before building. Co-authored-by: JJ Kasper <jj@jjsweb.site>

…ion (#64177) ### Why? The `next build` failed because it was trying to type check route-conventional files (page, layout, route) in the `_private` folder, which should not be considered as route segments. x-ref(CI): https://github.com/vercel/next.js/actions/runs/10907159175/job/30270204880?pr=64177#step:29:117 ### How? Don't generate type files for files that are under the `<app-dir>/**/_*` pattern. Fixes #64162 Closes NDX-283 Closes NDX-285

waiting for metadata is only necessary when `dynamicIO` is enabled. In the long run we will get rid of this waiting anyway when we have async dynamic APIs so we condition this behavior to be only when dynamicIO is on for now

…#68683)  ### What? sendGTMEvent pushes items to window.datalayer. THe GoogleTagManger (GTM) client uses this to know what events to the GTM server. currently if GTM is not ready, instead of adding events to the dataLayer, it writes a warning to the console saying GTM is not ready. The PR fixes that by defining the dataLayer if it is undefined so it can start to queue up events before GTM is ready https://developers.google.com/tag-platform/tag-manager/datalayer#how_data_layer_information_is_processed ### Why? If GTM init is slow we don't want to loose any events that we want to send before GTM init has happened we want to queue them up in the dataLayer Another use case for this behaviour, is that you can optionally initialise GoogleTagManager based on environment so you don't pollute GTM data when developing or running playright tests, but you can still evaluate what exists on the dataLayer to test if the correct events would be sent to GTM after testing interactions with the app. ### How? The PR fixes that by defining the dataLayer if it is undefined so it can start to queue up events before GTM is ready Fixes # fixes #66865 (discussion) fixes #68678 (issue) --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>

`dyanmicIO` enables a semantic where any uncached IO will be excluded from prerenders. Before PPR this means any uncached IO would bail out of static generation at build time and during revalidates. Route handlers have a similar ability to be statically generated at build and revalidate time however we recently changed the behavior to only be enabled if you explicitly opt into this using an API like `export const revalidate` or `export const dynamic = "force-static"`. With dynamic IO though we don't really need to be this restrictive. If you use `unstable_cache` or `fetch(..., { cache: 'force-cache' })` you are opting into caching so when dynamicIO is on we can infer that the GET handler is valid to cache as long as there is no uncached IO. So in this commit we restore static generation when `dynamicIO` is enabled.

### What? This allows fallback pages that have Partial Prerendering enabled to be revalidated in minimal mode. ### How? When a request comes in without any `x-now-route-matches` headers and has partial prerendering enabled, it will consider it a revalidation request for the fallback page.

@samcx

This PR updates the with-videojs example to use the App Router. Here are the changes that have been made: - Renamed the pages folder to the app folder. - Updated the routing for / files to align with the App Router. - Added the layout.tsx file as part of the App Router. - Updated the package.json file. The following actions were performed as part of this PR: - Ran `pnpm prettier-check `with no issues found. - Executed the `pnpm check-examples` script. CC: @samcx --------- Co-authored-by: samcx <sam@vercel.com>

This re-adds internal env variables to allow providing page paths directly for debugging purposes. This is NOT a public API and should not be leveraged outside of internal Next.js debugging. x-ref: #67134 x-ref: [slack thread](https://vercel.slack.com/archives/C04DUD7EB1B/p1726519130567199)

### Why? Since `URL.canParse` is incompatible with older browsers like Safari 16, we added `canParseUrl` util at #70215. x-ref: https://caniuse.com/?search=URL.canParse To improve maintenance, we decided to add polyfill for `URL.canParse`. x-ref: [slack thread](https://vercel.slack.com/archives/C07BVA6HM17/p1726664071636899?thread_ts=1726620161.450109&cid=C07BVA6HM17) Closes NDX-302 --------- Co-authored-by: Jiachi Liu <inbox@huozhi.im>

Remove the dependency `graceful-fs` and types. I have looked at the project and it is only used in one file, inside this file only `fs` is imported but not the functionality provided by the library, finally it uses the native one through `graceful-fs`, I have simplified the logic and removed the unnecessary library. The retry functionality is implemented in the file and is not used from the dependency Co-authored-by: torresgol10.it <torresgol10.itd@gmail.com> Co-authored-by: JJ Kasper <jj@jjsweb.site>

Pathfinder is only needed if [the `allsorts` `outline` feature](https://docs.rs/allsorts/latest/allsorts/#cargo-features) is enabled, but it looks like we don't actually use the `outline` feature? This should avoid breakages for us whenever the nightly rust simd APIs change.

### Why? As the file paths to the build outputs of `@next/polyfill-module` & `@next/polyfill-nomodule` may not be intuitive without context, added comments that describes it.

### What? - Supersedes #69344. - Enable tree shaking for production builds ### Why? The history of #69344 is too messy ### How? Closes PACK-3215

### What? The previous approach was not completely correct and had a race condition when data was propagated by the edge was being balanced. This caused aggregated data to be incorrect. This caused some issues to stick around while they shouldn't do that. ### How? Now it locks both node at the same time to make sure to balance them in a single lockstep.

Co-authored-by: Jiachi Liu <inbox@huozhi.im>

@leerob

### What? Adds Nitrogen AIO custom image loader to docs. ### Why? Help folks find Nitrogen AIO as an option for Image @leerob --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>

When calling `redirect` in a server action, the action handler will invoke a worker to fetch the RSC payload from the URL being redirected to, and will return it in the action request. This allows the redirect to be handled in a single request rather than requiring a second request to fetch the RSC payload on the URL being redirected to. As part of this special redirection handling, no action result is returned, so the action promise is resolved with `undefined`. As a result of this behavior, if your server action redirects to a page that has the same form that was just submitted, and you're leveraging `useActionState`, the updated state value will be undefined rather than being reset to the initial state. **More generally, redirect errors are handled by the client currently by simply resolving the promise with undefined, which isn't the correct behavior.** This PR will reject the server action promise with a redirect error, so that it'll be caught by our `RedirectBoundary`. Since React will remount the tree as part of the error boundary recovery, this effectively resets the form to it's initial state. If the action is rejected in a global `startTransition`, then it'll be handled by a global `error` handler, which will perform the redirect. And if it occurs outside of a transition, the redirect will be handled by a `unhandledrejection` handler. Because we're not able to apply the flight data as-is in the server action reducer (and instead defer to the navigation action), we seed the prefetch cache for the target page with the flight data from the action result so that we do not need to make another server roundtrip. We apply the same static/dynamic cache staleTime heuristics for these cache entries. Fixes #68549 Closes NDX-229

This whole test suite was disabled but only 2 tests rely on runtime logs, so this refactors the test to remove the runtime log dependency in favor of returning the output from the action and reading from the DOM.

This removes an inaccurate check that doesn't set a revalidate value if revalidate is `undefined` which can be the case for SSR app route pages. Also adds a regression test to ensure this doesn't break again. Fixes: #70213

This auto-generated PR updates the development integration test manifest used when testing Turbopack.

The `app_structure` Rust binding for Node.js is not used anywhere. It was introduced in #47737, but has never been integrated. Note: The removal is also part of #69680, but we hope to land this earlier in isolation to unblock work that builds on top of it.

### What? This fixes file path encoding differences between build and serve. Currently, file paths that get encoded via `encodeURIPath` (which uses `encodeURIComponent`): https://github.com/vercel/next.js/blob/c3475da0686eecbf9acc9b004e579a8e67288d70/packages/next/src/server/app-render/create-component-styles-and-scripts.tsx#L59-L61 But when matching files to serve, we use `encodeURI`: https://github.com/vercel/next.js/blob/c3475da0686eecbf9acc9b004e579a8e67288d70/packages/next/src/server/lib/router-utils/filesystem.ts#L191 This means that any file which contains reserved characters according to [RFC2396](https://datatracker.ietf.org/doc/html/rfc2396) will not match correctly. ``` reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," ``` Closes PACK-3266

This is a pure refactoring in preparation for introducing an `app_route_loader_tree` in a future PR. The `app_page_loader_tree` collects information from the app directory for app _page_ entries, whereas the upcoming `app_route_loader_tree` will collect information from the app directory tailored to app _route_ entries.

This is a pure refactoring in preparation for introducing an `app_route_loader_tree` in a future PR. It enables reusing common logic for injecting imported modules from the app directory into both page and route entries.

This is a pure refactoring. Not every reserved file in the app directory represents a component module. Currently, `route` is the only exception, but a future PR will introduce another one.

Fixes #70216 ### What? The `redirect` function from `next/navigation` does not honor the redirect type when used in server actions. When setting `type` to `replace`, the server action pushes to history instead of replacing the route. This stems from #54458 ### Why? The server action should honor the redirect type. ### How? By setting `x-action-redirect` header to `<url>;<redirectType>`, we extract the type of redirect to be performed on the client. This is handled in a way that if the type is absent, we fallback to `push`. Demo: https://github.com/user-attachments/assets/3c84c6e3-2b08-4df3-89b2-5f9d290cc5ff Observe that once the form is submitted and the action replaced the URL with `/`, we didn't go back to the `/child` route. --------- Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>

…69992) Without these APIs, the only way to construct a `ResolvedVc` was: ``` Vc::cell(my_value).to_resolved().await? ``` However, we know when calling `Vc::cell` that the `Vc` must be resolved (since we just assigned it to a cell), so we can shortcut that and provide a better API: ``` ResolvedVc::cell(my_value) ``` For `#[turbo_tasks::value]`s, there's an equivalent `.resolved_cell` method.

docs: fix the signature of CacheHandler#revalidateTag My tests shows that the `tags` could be an array. I have traced it back to the code: https://github.com/vercel/next.js/blob/af9b229074e39617bdd32d390fdc8f6a36d7bcde/packages/next/src/server/lib/incremental-cache/index.ts#L246-L248 --------- Co-authored-by: malewis5 <matthew.a.lewis7@gmail.com> Co-authored-by: JJ Kasper <jj@jjsweb.site>

This collects the few different isThenable and isPromise definitions into one shared function

@samcx

This PR updates the with-three-js example to use the App Router. Here are the changes that have been made: - Renamed the pages folder to the app folder. - Updated the routing for `/`, `/birds` & `/boxes` files to align with the App Router. - Added the `layout.tsx` & `tsconfig.json` file as part of the App Router. - Updated the package.json file. The following actions were performed as part of this PR: - Ran `pnpm prettier-check `with no issues found. - Executed the `pnpm check-examples` script. CC: @samcx --------- Co-authored-by: samcx <sam@vercel.com>

- Fixes #49772

Closes PACK-3254 1. Previously, guards were never removed, so a single if statement containing `if(clearImmediate)` would mean that it's valid in the whole file to use `clearImmediate` anywhere. Now it's only valid inside the bodies of conditional. I haven't seen any additional lints caused by this. 2. `if(process.env.NEXT_RUNTIME === 'edge')` guards are now respected There are new test cases for each of these. One new warning from this is the following from `react/cjs/react.development.js` where the unrelated `typeof` doesn't silence the error for `new MessageChannel()` anymore ``` function enqueueTask(task) { if (null === enqueueTaskImpl) try { var requireString = ("require" + Math.random()).slice(0, 7); enqueueTaskImpl = (module && module[requireString]).call( module, "timers" ).setImmediate; } catch (_err) { enqueueTaskImpl = function (callback) { !1 === didWarnAboutMessageChannel && ((didWarnAboutMessageChannel = !0), "undefined" === typeof MessageChannel && console.error( "This browser does not have a MessageChannel implementation, so enqueuing tasks via await act(async () => ...) will fail. Please file an issue at https://github.com/facebook/react/issues if you encounter this warning." )); var channel = new MessageChannel(); /// <--------- channel.port1.onmessage = callback; channel.port2.postMessage(void 0); }; } return enqueueTaskImpl(task); } ```

Co-authored-by: Jiachi Liu <inbox@huozhi.im>

These files are about to change. This commit just moves them to make diff and history tracking easier to follow

) The server component is going to be updated to be passed to a client component in a future update which is not possible. This change relocates where the root not found boundary is added to avoid creating an intermediate server component when the layout is a client component

Closes PACK-3123 Closes #66835 `baseUrl` has this odd behavior where it does **not** apply to JSON file imports. `ResolveModules::Path` is currently only used for `baseUrl`. Either: - we document that this is the behavior of `ResolveModules::Path` - or introduce some additional enum variant `ResolveModules::PathExceptJson` - or add an extension exclusion list to `ResolveModules::Path(Vc<FileSystemPath>, Vc<IndexSet<RcStr>>)` --- Here you can see that `tsc --traceResolution` doesn't look at `hypertune-nextjs-turbo-error/hypertune.json`: ``` ======== Resolving module 'hypertune' from '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/src/app/page.tsx'. ======== Explicitly specified module resolution kind: 'Bundler'. Resolving in CJS mode with conditions 'import', 'types'. 'baseUrl' option is set to '/Users/niklas/Desktop/hypertune-nextjs-turbo-error', using this value to resolve non-relative module name 'hypertune'. Resolving module name 'hypertune' relative to base url '/Users/niklas/Desktop/hypertune-nextjs-turbo-error' - '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/hypertune'. Loading module as file / folder, candidate module location '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/hypertune', target file types: TypeScript, JavaScript, Declaration, JSON. File '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/hypertune.ts' does not exist. File '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/hypertune.tsx' does not exist. File '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/hypertune.d.ts' does not exist. File '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/hypertune.js' does not exist. File '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/hypertune.jsx' does not exist. Directory '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/hypertune' does not exist, skipping all lookups in it. File '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/src/app/package.json' does not exist. File '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/src/package.json' does not exist. Found 'package.json' at '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/package.json'. Loading module 'hypertune' from 'node_modules' folder, target file types: TypeScript, JavaScript, Declaration, JSON. Searching all ancestor node_modules directories for preferred extensions: TypeScript, Declaration. Directory '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/src/app/node_modules' does not exist, skipping all lookups in it. Directory '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/src/node_modules' does not exist, skipping all lookups in it. Found 'package.json' at '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/node_modules/hypertune/package.json'. File '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/node_modules/hypertune.ts' does not exist. File '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/node_modules/hypertune.tsx' does not exist. File '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/node_modules/hypertune.d.ts' does not exist. 'package.json' does not have a 'typesVersions' field. 'package.json' does not have a 'typings' field. 'package.json' has 'types' field './dist/index.d.ts' that references '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/node_modules/hypertune/dist/index.d.ts'. File '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/node_modules/hypertune/dist/index.d.ts' exists - use it as a name resolution result. Resolving real path for '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/node_modules/hypertune/dist/index.d.ts', result '/Users/niklas/Desktop/hypertune-nextjs-turbo-error/node_modules/.pnpm/hypertune@2.5.2/node_modules/hypertune/dist/index.d.ts'. ```

- The Turbopack implementation does not have `unstable_allowDynamic` - Turbopack doesn't add import stacks currently as that makes the compilation of a module depend on the parent module.

We just forgot enabling them when implementing `@next/mdx` for Turbopack.

Closes PACK-3265 Closes #70186 We did detect `require` calls in ESM at build time, but that variable was not available *at runtime*

With the default derived implementation, serde would inject a `T: Serialize` or `T: Deserialize` bound. However, like `Vc`, `ResolvedVc` is serialized as a couple numeric IDs (the type of `T` doesn't matter), so we shouldn't have this restriction on `ResolvedVc`. Also, clean up `Vc<T>` using the same `bound = ""` trick with the derive macro.

> [!NOTE] > This codemod requires to install the `@vercel/functions` package. ### Why? Codemod support for breaking change at #68379. It removed the `ip`, and `geo` properties from the `NextRequest` type. The `NextRequest` type was mostly used in the `middleware` and `route`. ### How? The codemod replaces the `ip`, and `geo` properties from the `NextRequest` with corresponding `@vercel/functions` features. #### Accessing NextRequest Value When a file uses `NextRequest`, we look if there's an access to the type with `geo` or `ip`. This targets destructuring and direct access. ```ts export function GET (req: NextRequest) { const { geo, ip: ipAlias, pathname } = req // destructuring // direct access req.geo req.ip } ``` Declares a variable based on the identifier within the object. If it was aliased, we use the aliased name. ```ts import { geolocation, ipAddress } from '@vercel/functions' export function GET (req: NextRequest) { const { pathname } = req // destructuring const geo = geolocation(req) const ipAlias = ipAddress(req) // direct access geolocation(req) ipAddress(req) } ``` #### Accessing NextRequest Types When the file has accessed the `geo | ip` type from `NextRequest`, we replace with the corresponding types. ```ts import type { NextRequest } from 'next/server' export function GET (req: NextRequest) { const ip = '...' as NextRequest['ip'] const geo = { ... } as NextRequest['geo'] } ``` Since the type for `ip` is `string | undefined`, we explicitly replace it. For `geo`, we replace with the `Geo` type. ```ts import type { NextRequest } from 'next/server' import type { Geo } from '@vercel/functions' export function GET (req: NextRequest) { const ip = '...' as string | undefined const geo = { ... } as Geo } ``` ### Ref Behavior FYI: #70064 (comment), #70064 (comment) Closes NDX-291 --------- Co-authored-by: Sebastian Silbermann <silbermann.sebastian@gmail.com> Co-authored-by: Donny/강동윤 <kdy1997.dev@gmail.com> Co-authored-by: Jiachi Liu <inbox@huozhi.im>

--------- Co-authored-by: JJ Kasper <jj@jjsweb.site>

### What? Update the tip to also mention `app` directory when setting up TypeScript. ### Why? The user may be using App Router instead of Pages Router (or both). ### How? --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>

Ensures we don't overwrite freshly built assets over restored assets and ensures restore references in manifest are overwritten but not fully omitted. Also ensures we don't have conflicting cache enabled with this feature.

…fied by user (#70127) Fixes #70086 and #64864 (partially) ### What? When user wants to override for certain headers such as `content-type` or `cache-control` via `next.config` file or through middleware, nextjs sends multiple header values by combining the user's headers with its own default values for such headers. An example is demonstrated here: https://github.com/user-attachments/assets/7b38331b-9137-485d-9285-d0b0d0e1e5ac ### Why? Duplicate header values are a problem. ### How? Maintaining a list of headers which cannot have duplicate values, and then checking if the user has overridden any of those headers. If so, user overrides are respected and sent over. Demonstration of the correct behaviour after this fix: Using `next.config` file: https://github.com/user-attachments/assets/65e2aafb-dffc-47f4-bfcf-cf26a66865db Using `middleware`: https://github.com/user-attachments/assets/67636145-10eb-4504-ad78-800c1307c550 --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>

### What? Non-static HTTP methods contain `PUT` method, but there are two `POST` methods. ### How? Change one `POST` method to `PUT` method Co-authored-by: JJ Kasper <jj@jjsweb.site>

Stacked on #70328 When fallback params are passed to a layout we need to treat client component layouts special because passing the fallback params to the client component is otherwise enough to make them postpone. This change introduces a similar abstraction that we use for client component Pages where we pass our Page component to a PageRoot component which reifies the dynamically tracked params from the underlying params.

### What? https://nextjs.org/docs/app/building-your-application/optimizing/open-telemetry is partially outdated. ### Why? - As mentioned [here](https://github.com/open-telemetry/opentelemetry-js/blob/cdfefb829441f0c2765756d61078c39531c04d05/semantic-conventions/src/resource/SemanticResourceAttributes.ts#L649-L656), SEMRESATTRS_SERVICE_NAME has been deprecated. - Also, the default ESLint configuration generated by create-next-app triggers warnings about the import order. ### How? - so it has been changed to ATTR_SERVICE_NAME. - Also, fixed the import order. Co-authored-by: JJ Kasper <jj@jjsweb.site>

This is a small refactor in preparation for adding more logic to `createAppRouteCode` in a future PR. This change allows for a more focused diff when reviewing the upcoming PR. In this PR, all code lines are moved to the new file without any modifications.

… specifications (#68273) Co-authored-by: Jiachi Liu <inbox@huozhi.im>

This ensures we don't overwrite/copy stale middleware chunks with experimental tracing.

Ensure legacy env keys don't need to invalidate the whole build the same way we do for `NEXT_PUBLIC_`

…on. (#70364) ### What? Fixed a typo in the example comment for the [fetch options.cache](https://nextjs.org/docs/app/building-your-application/caching#fetch-optionscache) section. ### Why? The typo could lead to confusion, and correcting it ensures that the example is clear and professional. ### How? Updated the comment with the correct wording to reflect the intended message without changing the functionality of the example. Co-authored-by: JJ Kasper <jj@jjsweb.site>

This header isn't always able to be overridden so we shouldn't be asserting it specifically in our tests. x-ref: [slack thread](https://vercel.slack.com/archives/C04KC8A53T7/p1727138501597279?thread_ts=1727137032.335159&cid=C04KC8A53T7)

This auto-generated PR updates font data with latest available

We should not attempt to bundle builtin node modules on the server. This adds modules provided by Node.js to our externals list (along with some missing internal ones in Turbopack. These were copied from [here](https://github.com/vercel/next.js/blob/a675bde6c738318264573144663e38819aeb2661/crates/next-custom-transforms/src/transforms/warn_for_edge_runtime.rs#L77-L89)). Fixes #70262 Closes NDX-314

fixes a race condition in the `after()`-related test in `server-components-hmr-cache.test.ts` i made `getLoggedAfterValue` stricter while investigating an unrelated issue, and saw it occasionally throw (see [CI run](https://github.com/vercel/next.js/actions/runs/11001754094/job/30547234764?pr=70362#step:29:708)). before this change, if `getLoggedAfterValue` was called before any logs with `"After: "` were written, it would just return `undefined`, which is obviously not what the test wants. this seems to have been happening occasionally, but it wasn't visible because even if we got `undefined` from one of the calls, the `expect(valueBeforePatch).not.toEqual(valueAfterPatch)` assertion would still pass -- one of the values is a string and the other is `undefined`, so obviously they're not equal!

## Before: <img width="965" alt="Bildschirmfoto 2024-09-23 um 14 55 16" src="https://github.com/user-attachments/assets/26aabfdd-0e43-4dd2-a025-5eaf6a717043"> ## After: <img width="972" alt="Bildschirmfoto 2024-09-23 um 14 52 54" src="https://github.com/user-attachments/assets/3b7ce28a-c2ea-475b-ab53-ed9838546400"> ## The whole Turbopack module registry is hidden in `Next.js`: <img width="612" alt="Bildschirmfoto 2024-09-23 um 14 53 04" src="https://github.com/user-attachments/assets/a38295ad-90a7-49b2-a272-661e0b80bfbb">

- removes IncomingMessage/ServerResponse from accepted types, we never actually pass those - narrow down the possible combinations of req/res to what we actually use

This is of course still not great. Is there a way/will to have codeframes similar to vercel/turborepo#8879 when using Webpack? Before: ``` Error: page.mdx:Error: Message { place: Some(Point(7:1 (87))), reason: "Unexpected end of file in expression, expected a corresponding closing brace for `{`", rule_id: "unexpected-eof", source: "markdown-rs" } Import trace for requested module: ./app/blog/hello-world/page.mdx ⨯ ./app/blog/hello-world/page.mdx ``` After: ``` Error: page.mdx:Error: 7:1: Unexpected end of file in expression, expected a corresponding closing brace for `{` (markdown-rs:unexpected-eof) Import trace for requested module: ./app/blog/hello-world/page.mdx ⨯ ./app/blog/hello-world/page.mdx ```

Fixes PACK-3246

### Why? Switching between `canary`, `rc`, and `latest` also requires React version changes which could be time-consuming. This is essential for reproduction, confirming issue fixed on canary, and migration. Also, to run the codemods for breaking changes, users have to go through the documentation and find which codemods to run for their project. ### How? `@next/codemod upgrade` expects the user to select `canary`, `rc`, or `latest` version to upgrade. Also, it detects any possible codemods to run, and suggest the user whether to run it. https://github.com/user-attachments/assets/3aa3fee8-75f2-4178-b5ce-fef725109d6b --------- Co-authored-by: devjiwonchoi <devjiwonchoi@gmail.com>

### Why? All the `any` and `unknown` types kept bothering me. I've also removed some unused napi functions

Chunk each layout/page segment separately to deduplicate work across pages Fixes PACK-3272

) This PR adds a new feature to the existing `remotePatterns` allowlist configuration, that enables the ability to filter on `search` (aka query string). The most common usage will likely be `search: ''`, which means no query string allowed. You can also set the exact query string such as `search: '?v=1'` which can be useful to invalidate the cache one time for a specific version without opening the door to any version. Note the leading question mark to match the behavior of `new URL(url).search`.

…ic at the same route segment level (#70386) ## Why? Currently, we do not explain why you cannot have a separate static and dynamic slot at the same route segment level. - Fixes #70366 --------- Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>

…edVc types as arguments (#70269) ## Why? [We want to codemod structs to use `ResolvedVc<...>` for all of their field types instead of `Vc<...>`.](https://www.notion.so/vercel/Resolved-Vcs-Vc-Lifetimes-Local-Vcs-and-Vc-Refcounts-49d666d3f9594017b5b312b87ddc5bff?pvs=4) There are many constructor-like functions (see #70133) where we must accept an argument of type `Vc<...>`, and then explicitly call `.to_resolved().await?`. However, internally `#[turbo_tasks::function]` arguments are guaranteed to be resolved by the time the function runs. So we can do a cheap conversion here. ## What Instead of needing to do: ```diff #[turbo_tasks::value_impl] impl CustomProcessEnv { #[turbo_tasks::function] - pub fn new(prior: Vc<Box<dyn ProcessEnv>>, custom: Vc<EnvMap>) -> Vc<Self> { - CustomProcessEnv { prior, custom }.cell() + pub async fn new(prior: Vc<Box<dyn ProcessEnv>>, custom: Vc<EnvMap>) -> Result<Vc<Self>> { + let prior = prior.to_resolved().await?; + let custom = custom.to_resolved().await?; + Ok(CustomProcessEnv { prior, custom }.cell()) } } ``` It should now just be possible to accept `ResolvedVc` instead. The exposed function signature will be unchanged, still accepting `Vc` arguments, and a conversion will happen internally. ```diff #[turbo_tasks::value_impl] impl CustomProcessEnv { #[turbo_tasks::function] - pub fn new(prior: Vc<Box<dyn ProcessEnv>>, custom: Vc<EnvMap>) -> Vc<Self> { + pub fn new(prior: ResolvedVc<Box<dyn ProcessEnv>>, custom: ResolvedVc<EnvMap>) ->Vc<Self> { CustomProcessEnv { prior, custom }.cell() } } ``` This should also work for arguments where `Vc` is inside of a `Vec` or `Option` (other collection types are not currently supported). This PR does not support `self` arguments. That is handled by #70367. ## How - The macro inspects the argument type and rewrites it to replace `ResolvedVc` with `Vc` to get the exposed function's signature. - The `FromTaskInput` trait does the actual conversion. ### Why do this type expansion and conversion in the macro, and not as part of [the `TaskFn` trait](https://github.com/vercel/next.js/blob/8f9c6a86177513026ab4bc4fdc3575ca1efe025c/turbopack/crates/turbo-tasks/src/task/function.rs)? Without [specialization](https://github.com/rust-lang/rfcs/blob/master/text/1210-impl-specialization.md) it's not possible to implement the `FromTaskInput` trait for all `TaskInput` types, as we'd end up with overlapping impls for `Option<T>` and `Vec<T>`. There are specialization hacks ([inherent method specialization](dtolnay/case-studies#14), [autoref-specialization, and autoderef-specialization](http://lukaskalbertodt.github.io/2019/12/05/generalized-autoref-based-specialization.html)) but those hacks are mostly for macros, not for generic code: > One thing might be worth clarifying up front: the adopted version described here does not solve *the* main limitation of autoref-based specialization, namely specializing in a generic context. For example, given `fn foo<T: Clone>()`, you cannot specialize for `T: Copy` in that function with autoref-based specialization. For these kinds of parametricity-destroying cases, “real” specialization is still required. As such, the whole autoref-based specialization technique is still mainly relevant for usage with macros. So we need the macro to determine if a type implements `FromTaskInput` or `TaskInput`. We can't do this inside of generic function. Aside from that, even though it's not as technically correct, expanding the types inside the macro results in *much* more readable types in rustdoc, which is why we do this in `expand_vc_return_type` as well, even though we could use a trait's associated type instead: vercel/turborepo#8096 ## Test Plan ``` cargo nextest r -p turbo-tasks-memory test_resolved_vc cargo nextest r -p turbo-tasks-macros-tests function ``` Modify some code to use this, and use `rust-analyzer`'s macro expansion feature (after telling RA to rebuild proc macros).

…supported yet) (#70376) ## Why? We should update our documentation and also throw an error if somebody tries to use the `.mts` ( ES Module TypeScript) extension with `next.config`. We currently don't support this extension. - Fixes: #70201 --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>

@samcx

…70069) This PR updates the with-vercel-fetch example for using the App Router. Here are the changes that have been made: - Renamed the "pages" folder to the "app" folder. - Added the layout.tsx file as part of the App Router. - Updated the package.json file. CC: @samcx --------- Co-authored-by: samcx <sam@vercel.com>

#70269 adds support for `#[turbo_tasks::function]` to accept arguments of type `ResolvedVc<...>`, while still exposing a signature that uses `Vc<...>`. This PR allows them to also accept `ResolvedVc<...>` for `self`, using the nightly `arbitrary_self_types` feature. This re-uses the same mechanisms used for other arguments, with the added wrinkle that we can't shadow `self`, so we must rewrite the function body to replace references to `self` with `turbo_tasks_self`.

### What? This PR corrects and improves the documentation on the Data Fetching page, ensuring that the information is accurate and clear. ### Why? The previous version of the documentation contained inaccuracies or unclear explanations that could lead to confusion for developers. By addressing these issues, the documentation becomes more reliable and user-friendly. ### How? The changes involve updating the text to correct any misleading statements, adding clarity where necessary, and ensuring that all examples and explanations accurately reflect the intended data fetching process. --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>

…ignore)]` (#70375) This annotation implies that the field does not contain any `Vc` types, so we can re-use that here. We can skip checking for `ResolvedValue` on these fields. As we start codemodding stuff, we should consider renaming this annotation to something more generic (e.g. `#[turbo_tasks(does_not_contain_vc)]`), but this is good enough for now.

This ensures `env` keys in `next.config` are properly exposed during page collecting step during build since the inlining step comes after. x-ref: #70380 x-ref: https://vercel.com/vercel/vercel-site/9WqUX9vu15oVEy1acDqoXddcH27K?filter=errors

@samcx

This PR updates the ssr-caching example for using the App Router. Here are the changes that have been made: - Renamed the "pages" folder to the "app" folder. - Added the layout.tsx file as part of the App Router. - Updated the package.json file. CC: @samcx --------- Co-authored-by: samcx <sam@vercel.com>

- Fix `id` to be a string - Use `const` instead of `let` as common ESLint rules would complain otherwise - Add types to tsx files and remove some from jsx Co-authored-by: JJ Kasper <jj@jjsweb.site>

Updates the configuration to specify a boolean argument rather than string literals.

Fixes: https://github.com/vercel/next.js/actions/runs/11021874562/job/30610193528

## Why? - Refactor popular-prs workflow to `.ts` - Bump packages

Original PR is too out of sync so this lands separate. Closes: #66780

### What? Added a step in both `build-native.cjs` and `build-wasm.cjs` scripts to run Prettier on the generated types file after writing it. Should have been added with #69680, but I didn't think about it. Currently, every time you built the native module you have changes in the git repo (which would be fixed on commit, but graphite might not be happy with uncommitted changes).

Minor tweak to the wording of this section to better convey the behavior of `scroll: false`. "Restoration" can be interpreted as reinstating a previously saved scroll position for that route (as it happens when using `router.back()`), while what it actually does is preserving the current scroll position when navigating to a new route, by means of disabling the default "scroll to top" behavior. Related to: #57258, and #47781 (reply in thread) Co-authored-by: JJ Kasper <jj@jjsweb.site>

Lands #54317 as we can't update the history cleanly on that PR anymore Closes: #54317 Co-authored-by: Andrés Martínez <78830288+andresmarpz@users.noreply.github.com>

…ing (#65907)  A new gtmScriptUrl option has been added to the third-parties GTM package. This allows you to replace the default https://www.googletagmanager.com/gtm.js URL with a custom gtm.js URL, such as "https://gtm.example.com/gtm.js". Closes: #63767 Closes: #68531 Closes: #67161 Closes: #61145 Closes: #58262 --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>

### Why? Prerequisite of `@next/codemod upgrade`. Current status of next-codemod is difficult to extend another commands as it relies on [meow](https://www.npmjs.com/package/meow) which requires to handle args and flags manually. For consistency with `next` and `create-next-app`, migrated to `commander` and `prompts`. https://github.com/user-attachments/assets/8d2e53be-4b7d-4755-9a3f-c73df1f9ef7e No behavioral changes **except the help message**.

#70421) Noticed these files while reviewing #70242 Mark them as generated so that github & graphite collapse them when reviewing code. ``` $ git ls-files | git check-attr -a --stdin | grep __snapshots__ ``` ``` .config/ast-grep/rule-tests/__snapshots__/no-context-snapshot.yml: linguist-generated: true examples/with-jest-babel/__tests__/__snapshots__/snapshot.tsx.snap: linguist-generated: true examples/with-jest/__tests__/__snapshots__/snapshot.tsx.snap: linguist-generated: true examples/with-typescript-graphql/test/__snapshots__/index.test.tsx.snap: linguist-generated: true test/development/acceptance-app/__snapshots__/ReactRefreshLogBox.test.ts.snap: linguist-generated: true test/development/acceptance/__snapshots__/ReactRefreshLogBox.test.ts.snap: linguist-generated: true test/development/acceptance/__snapshots__/ReactRefreshLogBoxMisc.test.ts.snap: linguist-generated: true test/development/acceptance/__snapshots__/error-recovery.test.ts.snap: linguist-generated: true test/development/basic/__snapshots__/next-rs-api.test.ts.snap: linguist-generated: true test/production/eslint/test/__snapshots__/next-build-and-lint.test.ts.snap: linguist-generated: true ```

Closes: https://github.com/vercel/next.js/pull/58589/files

Closes: #59342

### What? Minor refactorings extracted from other PRs. ### Why? To make WIP small

…ses (#70412) Noticed this pattern while touching `turbo-tasks-fs`. Functions that take `self: Vc<Self>` and immediately await it without ever using the `Vc` version of the argument should just take `&self` as an argument. There are some remaining cleanup opportunities here, which I have some still-WIP codemods for: - [x] If we have a trivial `let this = self` or `let this = &self.0`, we should rewrite references to `this` to use `self`. *Done in #70431* - [ ] If we can be sure that a function never returns anything other than `Ok(...)`, we should remove `Result` from the return type. Those changes need to be performed as a separate codemod pass due to limitations with `ast-grep`. ## How? ast-grep: https://ast-grep.github.io/ Using the ast-grep config: https://gist.github.com/bgw/b7bc0a921cf3e3447acaf8feda60b518 Ran it with: ``` sg scan -U -r ../codemod_rewrite_vc_self.yml . ``` ## Should this be a lint? **Maybe.** I've managed to get the false-positive rate down to zero on our existing codebase (at the cost of missing some opportunities for cleanup). ast-grep supports running as a lint rule, and this can be autofixed. However, if we fix the `let this = ...` and `Result<...>` cases as well with additional lint rules, **this might be a bit annoying as it'll trigger cascading lint rules**. You *might* need to run the linter multiple times for it to eventually settle. It does not appear to be possible to do all these changes in a single lint rule, as we require modifying overlapping ranges of code (which ast-grep sadly doesn't seem to support with the `rewriters` rules). We should also consider `dynlint` before heavily investing into `ast-grep` as a linter: https://github.com/trailofbits/dylint

### What? * While looking for server component entries and client components, look for server utils too * Create a separate chunk group for server utils * Mark all user imports in the rsc entrypoint has server component entries * Fix order of imports to allow proper caching --------- Co-authored-by: Niklas Mischkulnig <4586894+mischnic@users.noreply.github.com>

Closes PACK-3275 Among other things, a regression from #70255, but it could also happen with `__dirname`. To prevent `SyntaxError: Identifier 'require' has already been declared`

Occurs for example in ``` Failed to load chunk server/chunks/08b5e__pnpm_560cbe._.js .... Caused by SyntaxError: Identifier 'require' has already been declared .... ```

### What? Add `@taskr/esnext` to the root package.json to get around hoisting rules breaking `taskr`'s automatic discovery (and fix builds on some platforms where it is broken). ### Why? Some types of 'magically' imported packages (such as taskr automatically supporting es6 by just adding a package, or drizzle automatically finding a database driver) aren't hoisted on some platforms in the way the tool expects, breaking it. The symptom of this is taskr throwing a syntax error on some platforms, because we use ES6 syntax and it can't find the package it needs to support it. ### How? By adding it to the root package.json we ensure it is always hoisted in the way taskr expects.

Closes PACK-3276

A follow-up to the #70431 codemod diff, which leave behind a lot of trivial `let this = self;` statements. Using the following ast-grep rule config: ```yaml language: rust id: inline_trivial_this utils: block-with-this: all: - pattern: $BLOCK - kind: block - has: all: - pattern: let this = $SELF; - any: - pattern: let this = self; - pattern: let this = &self.0; rule: matches: block-with-this rewriters: - id: remove-let-this rule: pattern: let this = $SELF; fix: "" - id: inline-this-auto-deref rule: pattern: this inside: kind: field_expression transform: SELF_AUTO_DEREF: replace: source: $SELF replace: "&?(?<INNER>.*)" by: "$INNER" fix: $SELF_AUTO_DEREF - id: inline-this rule: pattern: this fix: $SELF transform: NEW_BLOCK: rewrite: source: $BLOCK rewriters: - remove-let-this - inline-this-auto-deref - inline-this fix: $NEW_BLOCK ``` Applied with ``` sg scan -U -r ../codemod_inline_trivial_this.yml . ```

### What? This PR fixes a numbering issue in the example code of the documentation. The comments in the code jumped from step 3 to step 5, so I renumbered them to maintain the correct sequence. ### Why? Correcting the comment numbering improves the clarity and readability of the code, ensuring that readers can follow the steps in the right order. ### How? I changed step 5 to step 4 and step 6 to step 5, adjusting the comment sequence without altering the logic or functionality of the code. ### Evidence ![image](https://github.com/user-attachments/assets/12b15de3-2cc3-4dca-9185-cde5a97cd0c3) Co-authored-by: JJ Kasper <jj@jjsweb.site>

Co-authored-by: Jiachi Liu <inbox@huozhi.im>

…70243) ### What? * switch remove vs change order * take_collectibles does not need to return an Option * avoid double Option * fix edges set bugs * remove collectibles from outdated collectibles * remove unneccessary remove

Co-authored-by: JJ Kasper <jj@jjsweb.site>

### What? Update the docker with multiple env examples by the correct hostname. ### Why? I am verry happy when I see this example, I need to deploy a project with multiple environments, I tested current example for my machine, but it started but it didn't connect to app. I really try this example https://github.com/vercel/next.js/tree/canary/examples/with-docker-multi-env. but it doesn't connect to nextjs container because the hostname configuation is incorrect. ### How? I created this PR to change hostname from host ```localhost``` to ```0.0.0.0``` in docker with multiple environments Closes NEXT- No fixing any issues Co-authored-by: JJ Kasper <jj@jjsweb.site>

This adds and updates some Typescript types for the React libraries used by Next.js. As a result some of the code was modified to match.

x-ref: #70410 x-ref: #70435

This aims to provide more stability so we aren't hitting the network to grab the validator more than we need to and instead leverage the one from build instead which should also reduce some test flakiness we've been seeing.

@samcx

This PR updates the with-draft-js example for using the App Router. Here are the changes that have been made: - Renamed the "pages" folder to the "app" folder. - Added the layout.tsx file as part of the App Router. - Updated the package.json file. CC: @samcx --------- Co-authored-by: Sam Ko <sam@vercel.com>

Next.js has a number of dynamic APIs that aren't available during prerendering. What happens when you access these APIs might differ depending on the mode you are using, for instance if you have PPR turned on or the newly introduced `dynamicIO` experimental mode. But regardless of the mode the underlying API represents accessing something that might only be available at render time (dynamic rendering) rather than prerender time (build and revalidate rendering) Unfortunately our current dynamic APIs make certain kinds of modeling tricky because they are all synchronous. For instance if we wanted to add a feature to Next.js where we started a dynamic render before a Request even hits the server it would be interesting to be able to start working on everything that does not rely on any dynamic data and then once a real Request arrives we can continue the render and provide the associated Request context through our dynamic APIs. If our dynamic APIs were all async we could build something like this because they represnt a value that will eventually resolve to some Request value. This PR updates most existing dynamic APIs to be async rather than sync. This is a breaking change and will need to be paired with codemods to realistically adopt. Additionally since this change is so invasive I have implemented it in a way to maximize backward compatibility by still allowing most synchronous access. The combination of codemods, typescript updates, and backward compat functionality should make it possible for projects to upgrade to the latest version with minimal effort and then follow up with a complete conversion over time. #### `cookies()` `cookies()` now returns `Promise<ReadonlyRequestCookies>`. Synchronous access to the underlying RequestCookies object is still supported to facilitate migration. ```tsx // ------------ preferred usage // async Server Component const token = (await cookies()).get('token') // sync Server Component import { use } from 'react' //... const token = use(cookies()).get('token') // ------------ temporarily allowed usage // javascript, dev warning at runtime const token = cookies().get('token') // typescript, dev warning at runtime import { type UnsafeUnwrappedCookies } from 'next/headers' // ... const token = (cookies() as unknown as UnsafeUnwrappedCookies).get('token') ``` #### `headers()` `headers()` now returns `Promise<ReadonlyHeaders>`. Synchronous access to the underlying Headers object is still supported to facilitate migration. ```tsx // ------------ preferred usage // async Server Component const header = (await headers()).get('x-foo') // sync Server Component import { use } from 'react' //... const header = use(headers()).get('x-foo') // ------------ temporarily allowed usage // javascript, dev warning at runtime const header = headers().get('x-foo') // typescript, dev warning at runtime import { type UnsafeUnwrappedHeaders } from 'next/headers' // ... const header = (headers() as unknown as UnsafeUnwrappedHeaders).get('x-foo') ``` #### `draftMode()` `draftMode()` now returns `Promise<DraftMode>`. Synchronous access to the underlying DraftMode object is still supported to facilitate migration. ```tsx // ------------ preferred usage // async Server Component if ((await draftMode()).isEnabled) { ... } // sync Server Component import { use } from 'react' //... if (use(draftMode()).isEnabled) { ... } // ------------ temporarily allowed usage // javascript, dev warning at runtime if (draftMode().isEnabled) { ... } // typescript, dev warning at runtime import { type UnsafeUnwrappedDraftMode} from 'next/headers' // ... if ((draftMode() as unknown as UnsafeUnwrappedDraftMode).isEnabled) { ... } ``` #### `searchParams` `searchParams` is now a `Promise<{...}>`. Synchronous access to the underlying search params is still supported to facilitate migration. ```tsx // ------------ preferred usage // async Page Component export default async function Page({ searchParams }: { searchParams: Promise<{ foo: string }> }) { const fooSearchParam = (await searchParams).foo } // sync Page Component import { use } from 'react' export default function Page({ searchParams }: { searchParams: Promise<{ foo: string }> }) { const fooSearchParam = use(searchParams).foo } // ------------ temporarily allowed usage // javascript, dev warning at runtime export default async function Page({ searchParams}) { const fooSearchParam = searchParams.foo } // typescript, dev warning at runtime import { type UnsafeUnwrappedSearchParams } from 'next/server' export default async function Page({ searchParams }: { searchParams: Promise<{ foo: string }> }) { const syncSearchParams = (searchParams as unknown as UnsafeUnwrappedSearchParams<typeof searchParams>) const fooSearchParam = syncSearchParams.foo } ``` #### `params` `params` is now a `Promise<{...}>`. Synchronous access to the underlying params is still supported to facilitate migration. It should be noted that while params are not usually dynamic there are certain modes where they can be such as fallback prerenders for PPR. ```tsx // ------------ preferred usage // async Segment Component export default async function Layout({ params }: { params: Promise<{ foo: string }> }) { const fooParam = (await params).foo } // sync Segment Component import { use } from 'react' export default function Layout({ params }: { params: Promise<{ foo: string }> }) { const fooParam = use(params).foo } // ------------ temporarily allowed usage // javascript, dev warning at runtime export default async function Layout({ params}) { const fooParam = params.foo } // typescript, dev warning at runtime import { type UnsafeUnwrappedParams } from 'next/headers' export default async function Layout({ params }: { params: Promise<{ foo: string }> }) { const syncParams = (params as unknown as UnsafeUnwrappedParams<typeof params>) const fooSearchParam = syncParams.foo } ``` ### Typescript Changes When using typescript with Next.js currently it is up to you to author types for Pages, Layouts and other Segment components that recieve props like `params` and `searchParams`. Next comes with some build-time type checking to ensure you have not improperly typed various top level module exports however the current type assertions for `params` and `searchParams` is `any`. This isn't very helpful because it allows you to erroneously type these props. `searchParams` is tricky because while the default type is a dictionary object parsed using node.js url parsing it is possible to customize when running a custom Next.js server. However we can ensure that you correctly type the prop as a Promise so with this change the validated type for `searchParams` will be `Promise<any>`. In the long run we will look at updating the `searchParams` underlying type to be URLSearchParams so we can move away from supporting customized parsing during rendering and we can get even more explicit about valid types. `params` is more straight forward because the framework controls the actual `params` prop implementation and no customization is possible. In the long run we want to enforce you are only typing params that are valid for the Layout level your file is located in but for now we are updating the allowed type to be `Promise<{[key: string]: string | string[] | undefined }>`. These new type restrictions may also require fixes before being able to successfully build a project that updates to include these breaking changes. These changes will also not always be codemodable because it is valid to type the entire component using an opaque type like `Props` which our codemods may not have an ability to introspect or modify.

This behavior is differing when deployed causing failures. [x-ref](https://github.com/vercel/next.js/actions/runs/11042054253/attempts/2) [x-ref](https://github.com/vercel/next.js/actions/runs/11041870219/attempts/2)

…and update `sassOption` types (#70428) ## Why? We currently don't document the `implementation` property for `sassOptions`. Since this is one our maintained properties, we should also update the types for `sassOptions`. - Fixes #70020 --------- Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com> Co-authored-by: JJ Kasper <jj@jjsweb.site>

### What? Use `pure` property to check if we need a group ### Why? To reduce the number of internal parts.

…70474) I left a bunch of these behind in #70412 . This cleans them up. The only remaining work after this is removing unused `Result<...>`s from return types. ast-grep config: ```yaml language: rust id: remove_unused_async_keyword rule: pattern: async inside: kind: function_modifiers inside: kind: function_item follows: pattern: context: | #[turbo_tasks::function] selector: attribute_item stopBy: not: kind: attribute_item has: field: body not: has: any: - kind: await_expression - pattern: context: foo!($$$ await $$$) selector: token_tree inside: kind: macro_invocation stopBy: end stopBy: any: - kind: function_item - kind: async_block - kind: closure_expression fix: "" # these files have intentionally async functions ignores: - "**/turbo-tasks-testing/**" - "**/turbo-tasks-memory/tests/**" ``` Applied with: ``` sg scan -U -r ../codemod_remove_unused_async_keyword.yml . && cargo fmt ```

## Why? There is no mention of what the default port is when you `next dev --experimental-https`. x-ref: https://x.com/rauchg/status/1839092783392632867 --------- Co-authored-by: Will Binns-Smith <wbinnssmith@gmail.com>

It's a bit odd that we expose this internal debugging capability in production and it seems to cause potential production issues when serializing unsupported data structures ([x-ref ](#69436)) If we feel a need to re-introduce the ability to introspect on the router state even in production we could consider relanding it in an opt-in way, and not run on every action. But I think since we've moved away from throwing promises in reducers (back when the reducers could potentially be replayed by React, in early Suspense implementations), I'm not sure this provides as much value. Fixes #70441

### What? Add evaluation logic for cases where we are sure that the result is a number and not a string. ### Why? It's required for DCE.

…turbo_task::function]`s (#70492) The `#[turbo_tasks::function]` macro always exposes a `impl Future<Output = Result<ReadRef<T>>>`, regardless of the function's actual return type. We only need to use a `Result<...>` return type when the function can fail. If it's infallible, this just adds noise. I left a bunch of these behind in #70412, plus I think we had a lot of these independent of that PR. This cleans them up. ```yaml language: rust id: remove_unused_result_return_type utils: last-expression-inside-block: any: - inside: # single-line blocks just have the expression as the only child kind: block nthChild: position: 1 reverse: true - inside: # multi-line blocks wrap their final expression in an expression_statement kind: expression_statement inside: kind: block nthChild: position: 1 reverse: true ok-expression: kind: call_expression any: - pattern: Ok($_ARG) - pattern: $$$::Ok($_ARG) ok-expression-capturing: kind: call_expression any: - pattern: Ok($ARG) - pattern: $$$::Ok($ARG) # ast-grep does not appear to allow utils to be recursive, split out "simple blocks", and limit supported nesting simple-block-with-implicit-ok-return: kind: block has: nthChild: position: 1 reverse: true matches: ok-expression simple-expression-ok-value: any: - matches: simple-block-with-implicit-ok-return - kind: if_expression all: - has: field: consequence matches: simple-block-with-implicit-ok-return - has: field: alternative has: matches: simple-block-with-implicit-ok-return - kind: match_expression has: field: body not: has: kind: match_arm has: field: value not: any: - matches: ok-expression - matches: simple-block-with-implicit-ok-return block-with-implicit-ok-return: any: - matches: simple-block-with-implicit-ok-return - kind: block has: nthChild: position: 1 reverse: true any: - kind: expression_statement has: matches: simple-expression-ok-value - matches: simple-expression-ok-value # single-line blocks don't result-return-type: pattern: context: fn func() -> Result<$INNER_RET_TY> {} selector: generic_type infallible-fn: # this function only appears to return `Ok(...)`, it does not use try_expression (`?`) or `anyhow::bail!(...)` kind: function_item not: has: field: body any: - not: matches: block-with-implicit-ok-return - has: stopBy: kind: function_item any: - kind: try_expression - pattern: "?" inside: kind: macro_invocation stopBy: end - pattern: bail!($$$) - pattern: $$$::bail!($$$) - kind: return_expression not: has: matches: ok-expression rule: all: - pattern: $FUNC - kind: function_item has: field: return_type matches: result-return-type follows: pattern: context: | #[turbo_tasks::function] selector: attribute_item stopBy: not: kind: attribute_item - matches: infallible-fn rewriters: # this rewriter is far from perfect, and might rewrite too much - id: rewrite-return-type rule: matches: result-return-type inside: kind: function_item field: return_type fix: $INNER_RET_TY - id: unwrap-ok-values rule: all: - matches: ok-expression-capturing - any: - matches: last-expression-inside-block - inside: kind: return_expression - inside: kind: match_arm fix: $ARG transform: NEW_FUNC: rewrite: rewriters: - rewrite-return-type - unwrap-ok-values source: $FUNC fix: $NEW_FUNC ignores: - "**/turbo-tasks-testing/**" - "**/turbo-tasks-memory/tests/**" ``` ``` sg scan -U -r ../codemod_remove_unused_result_return_type.yml && cargo fix --lib --allow-dirty && cargo fmt ``` I used `cargo fix` in this case to auto-remove the now-unused `anyhow::Result` imports. I manually fixed clippy lints that now violated the `let_and_return` lint rule (using a separate commit inside this PR), as `cargo clippy --fix` seemed to hang when processing our `build.rs` files?

Co-authored-by: Sam Ko <sam@vercel.com> Co-authored-by: Jiachi Liu <inbox@huozhi.im>

This is because CI info will be used by other modules of the server, not just Telemetry. This refactoring doesn't change any functionalities.

The closure encryption utilities need the same module maps as use-cache-wrapper. We can share the same singletons. Using singletons for this is sketchy because if concurrent requests switches to another page with a different manifest, it would potentially have missing entries. We should ideally use AsyncLocalStorage but this is not making anything worse and any solution should apply to both. This doesn't actually make anything new work. Because you can't pass a Server References into these functions since React doesn't yet allow Server References inside the RSC layer to be encoded through encodeReply. We could. One thing to note there is that if we do allow that then the id of the Server Reference ideally includes the hash of its implementation (not just Cache IDs) because if the implementation can change without the id then passing a Server Reference as an argument to "use cache" and calling it within the cache should not reuse results if the implementation changes. It also doesn't yet work to pass Client References out of these functions because the SSR manifest is missing. That is already missing for encryption too and we should pass the same thing into both there. This clarifies that in either case we should always pass null for moduleLoading because that's only used for SSR and would lead to unnecessary preloads to be added if we replayed the preloads that are already covered by client references.

…ges (#70477) We previously supported a legacy mode of exporting a `getStaticPaths` from app directory pages. This removes that option in favour of `generateStaticParams`.

Ensures Webpack build and Turbopack build results for the heavy-npm-deps benchmark are uploaded to DataDog so that we can track them over time.

This just moves the zod helper utilities into it's own file so we can re-use it in future PR's.

This enhances the experimental debugging mode for Partial Fallback Prerendering to only render the fallback shell.

We want to immediately expire any stale entries from memory caches. So we just have treat them as missing/expired directly.

…n with dynamic = "error" (#70534) When producing a fallback shell params is dynamic. Normally anything dynamic shoudl be a build error when `export const dynamic = "error"` is used. however for fallback shells we'll never have fully static shells, nor should we since the whole point is to produce a PPR shell that server a wide range of paths. In the refactor for async dynamic APIs I introduced a bug where fallback param dynamic also errored if `export const dynamic = "error"` was used. This change corrects this behavior and adds a corresponding test

As discussed this adds an in memory cache scope which is leveraged for seeding during prefetch and then leveraged during non-prefetch requests in development and during build it shares a cache scope across one build worker. During production server mode the cache scopes are specific per-request with no prefetch cache seeding.

RSC has never supported the `errorInfo` argument to `onError` unlike SSR. This PR updates our usage of onError in RSC contexts to clarify that this value does not exist This also updates the next interned types for react-dom/server to reflect that `renderTo...` and `prerender` support the `ErrorInfo` second arg and `resume` does not.

New CI budget is not approved yet and the hydration tests are flaky. There's no active work on Pages router so this is safe-ish to ignore to unblock work on App router which doesn't run on the installed React anyway.

As discussed this allows customizing the cache handler via env instead of only in `next.config`.

…70542) Currently our Action IDs don't include hashing of the implementation which they ideally should, or at least have a separate ID for that. This means it is not safe to reuse cache entries across deployments since the Action ID can remain unchanged. For now we include the build ID as part of the cache key to ensure we don't use cache entries. We should remove this or replace it with the hash of the Action later.

route.ts files (and other routes like metadata routes) still need dynamicIO semantics when runnign in edge runtime. This change adds support for configuring dynamicIO for edge routes. It is hard to test properly because edge routes never statically generate and at the moment there are no other observable semantics. If we introduce new semantics that are distinct for dynamicIO that affect dynamic rendering we should update these tests to assert them. Similarly generateStaticParams also needs dynamicIO semantics when configured. Right now it's not quite possible to assert this because there are no observable semantics. We should have one which is that fetchCache is not configurable with dynamicIO on however that isn't implemented yet. This change adds tests but they will need to be updated once we update the fetchCache behavior

For facebook/react#30741 This PR adds several additional parameters to the `createServerReference` calls generated by the Server Reference SWC transform, to later enable React to map server actions that are imported into client components back to their server locations (dev mode only). Currently the inner `findSourceMapURL` function is not yet implemented. In a follow-up we will unwrap `registerServerReference` as well, which is needed for server actions in the react server layer. --------- Co-authored-by: Hendrik Liebau <mail@hendrik-liebau.de>

Ensures there is no error running Tailwind with webpack in this benchmark.

Adds a `prefetch` prop to Form. It mirrors how Link's `prefetch` works, but it only allows `prefetch={false}` (no prefetching) and `prefetch={null}` ("auto" prefetch, the default). `prefetch={true}` does not make sense for Form. I don't expect this to be used much, because prefetching is one of the main parts of Form's functionality, but i think it's good to have the option to disable prefetching (even if mostly as an escape hatch)

### What? Execute revalidations (written into `staticGenerationStore.{revalidatedTags,pendingRevalidates,pendingRevalidateWrites}`) that were added during `unstable_after` callbacks. ### Why? Previously, if `revalidatePath`/`revalidateTag` were called in an `unstable_after` callback, nothing would happen. I missed the fact that other codepaths (app-render, action-handler, app-route) all [manually call `staticGenerationStore.incrementalCache.revalidateTag`](https://github.com/vercel/next.js/blob/79f4490b0abda3fa7129c49b402dbadf6eadd79e/packages/next/src/server/app-render/app-render.tsx#L1072-L1080) to actually perform revalidations scheduled via `revalidatePath`/`revalidateTag`, and `after-context` wasn't doing that, so nothing was happening.

…70554) Ensures more modules are compiled for the heavy-npm-deps benchmark in order to track performance wins better.

…nchmark" (#70561) Reverts #70554

…rams and searchParams (#70568) params and searchParams are now promises however to facilitate migration params and searchParams can still be referenced directly on these props. There are a number of special properties however that conflict with this and this change special cases more property names to not be synchronously accessed. We exclude common Object prototype properties, Promise prototype properties, and properties that are commonly existence tested like toJSON and displayName.

This adjusts the implementation of prefetched alias handling to be no longer be sprinkled throughout the existing navigation handler. Ultimately the goal will be to delete this handling once we have per-segment fetching, so keeping it in a single place will make that easier to do. This PR introduces a few changes to the previous behavior: - If we've determined an alias is to be used, it will recursively copy the canonical search params into the `FlightRouterState`. This is because an aliased entry won't necessarily correspond with the search params for the URL being navigated to, and we encode search params into the `FlightRouterState`. - Now we check to see if the aliased entry has any loading segments. If not, there's no work to be done, so we return to the regular navigation behavior and kick off a temporary prefetch for the page being navigated to. - In the case of constructing a new tree (ie from a navigation corresponding with a static page or something that started rendering from the root), previously we were only copying the root level into the cache. This updates the handling to construct a full tree with only the loading segments. Caught by failing test in #68305 when used with PPR, so this re-enables that test.

When only the hash fragment changes there's no reason to read anything from the server. The `onlyHashChange` logic was spilling out into places that shouldn't really care about it (like ppr-navigations) when really we just want to update some state flags and exit early. --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>

… value (#70570) The reasoning is that React only reads this after having set it. As long as we allow this to be written to we can set it to the param or searchParam value initially.

This PR extends the cache directive to accept an additional type parameter which defaults to `"default"`. Several follow-ups: - Accept different syntaxes (like places of spaces) and typo detection; - Have a limited set of valid options with better errors.

Co-authored-by: Jiachi Liu <inbox@huozhi.im>

Co-authored-by: JJ Kasper <jj@jjsweb.site>

…ices for Multi-Zones (#70565)  --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>

Spent over 2 hours checking why with 13.4.19 components didn't mount twice as the docs says "Good to know: Since Next.js 13.4, Strict Mode is true by default with app router". But it's enabled by default in [13.5.1](https://github.com/vercel/next.js/releases/tag/v13.5.1). Version [13.5.0](https://github.com/vercel/next.js/releases/tag/v13.5.0) has no changelog? Maybe reactStrictMode it's enabled by default since 13.5.0 instead 13.5.1 ? Fixes: #70559 Co-authored-by: JJ Kasper <jj@jjsweb.site>

In #68812 I updated most dynamic APIs to be async. One API that was not udpated was `unstable_noStore()`. This API is marked as unstable and doesn't quite fit the semantics we're exploring with dynamicIO and partial prerendering and so rather than converting it to be async we're going to deprecate it and replace it with an entirely new API. This PR doesn't actually deprecate anything yet but it does introduce `connection()`. The idea with `connection` is that you are waiting until there is a real user Request before proceeding. In the context of prerendering no Request will ever happen so the page cannot produce a static result. (this is similar to how `unstable_noStore()` works today). In a PPR context the currently rendering component won't resolve but a parent Suspense boundary can still statically render a fallback. `connect()` returns a `Promise<void>`. It is tempting to call the API `request()` and return a `Promise<Request>` however we have to guard access to the underlying Request carefully to ensure we can maximally prerender pages and to avoid confusion and maybe some frustration we are naming it `connection` since this doesn't imply a specific data set that might be returned. ``` import { connection } from 'next/server' async function MyServerComponent() { await connection() // everthing after this point will be excluded from prerendering const rand = Math.random() return <span>{rand}</span> } ```

### Fixing a bug Fix #70335 ### What? see #70335 ### Why? ### How? As for fetch standard, I think it should make filename decode with utf-8 by default https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#constructing-form-data-set  Co-authored-by: JJ Kasper <jj@jjsweb.site>

This test relied on `layout.js` being automatically written but that isn't the case with Turbopack (as documented). Fixed the test by adding the file that was magically generated.

Initially the non-PPR `dynamicIO` implementation used some experimental React APIs. This change updates the technique to only depend on APIs in the canary channel and updates the packaging rules to only not opt into experimental react when dynamicIO is enabled. Other experimental flags can still opt you into experimental react such as PPR.

…70572) In the PPR navigations flow, we were always spawning a pending task for page segments, which seemed to be related to search params not updating. (x-ref: #60242) However this case doesn't seem to be necessary: the static prefetch shouldn't contain any data related to search params, as accessing search params will postpone and trigger suspense fallbacks. And when the dynamic request sends down segment key information for page segments search params, the params will be encoded in the segment key (e.g. `__PAGE__{'foo': 'bar'}`, as opposed to just `__PAGE__`. I can't think of another case where this handling would be necessary as if we are in a new tree, we'll already spawn a pending task. And if we're in the same tree, I expect the static data should be the same, while the dynamic request will contain the different data.

## What? Skips a test that checks `.babelrc` with Turbopack.

Improve consistency by using the term that is already in use in the document.  --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>

### What? Updated the documentation for `next/head` to clarify how `<title>` and `<base>` tags are handled uniquely. Specifically, the documentation states that these tags are automatically checked for duplicates by Next.js and do not require the `key` attribute. ### Why? The current documentation suggests using the `key` attribute to prevent duplicate tags in the `head`. However, `<title>` and `<base>` tags are automatically managed by the `unique` function in Next.js (`head.tsx`), ensuring only one instance is rendered without needing a `key`. This update provides clearer guidance and prevents potential misunderstandings. ### How? - Added a note explaining that `<title>` and `<base>` tags do not need a `key` attribute as they are automatically checked for duplicates by Next.js. ### Reference Source code confirming this behavior: [head.tsx#L85-L93](https://github.com/vercel/next.js/blob/3ead2d1fe98f78307861b12983c76d5a7a88c41a/packages/next/src/shared/lib/head.tsx#L84-L93) <img width="741" alt="Window" src="https://github.com/user-attachments/assets/a3a6f3fd-6aab-48a2-8d15-26df0692b0e1"> Co-authored-by: JJ Kasper <jj@jjsweb.site>

This ensures we exit the RequestStorage/PrerenderStorage context and anything else but keeps the StaticGenerationStore (which should no longer have page/request specific information). I also create new CacheStore which will be used for life/tags but for now is just used to provide a better error when cookies/headers/draftMode are accessed within the cache scope. I tried to make `React.cache` AsyncLocalStorage scope be shared between the invocation of the cached function and anything it renders later. This is also necessary in case the cached function calls Float methods like `preload()`. However, I hit issues with preserving debug info, having the right owner and that rendering a Promise in a Server Component turns it into a `React.lazy` for now which doesn't preserve the type we want. The proper solution is for React to expose a larger scope for `React.cache` and float.

…0446) Fixes #70403 ### What? When `revalidateTag()` is called directly in server components, the cache is not purged for the corresponding tags. Reproduction steps available in #70403 ### How? Check [app-render.tsx](https://github.com/vercel/next.js/compare/canary...abhi12299:fix-revalidatetag-rsc?expand=1#diff-a3e2e024db1faa1b501e0dd6040eaaf0d931cb9878ae0fb0f4c3658daa982768) This issue was introduced in #65296 in this file: [revalidate.ts](https://github.com/vercel/next.js/pull/65296/files#diff-7f0cb5bb30d44b9153d724e31c25859b9aab6cc258b35563a1d9464cd0688283). The lines removed from the file resulted in the revalidation checks to be skipped when there is an RSC request. Also fixed checks on `pendingRevalidates` to also check for `revalidatedTags`. --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>

…ns (#70625)

When `dynamicIO` is enabled there is a prospective render used to fill caches. Previously we ignored errors during this phase. However this might mask user errors that are flakey. With this change we consider errors during the prospective render valid and throw them to the same handling logic that handles errors for the final render. We exclude control errors like prerender complete and prerender interrupted.

--------- Co-authored-by: Will Binns-Smith <wbinnssmith@gmail.com> Co-authored-by: Benjamin Woodruff <benjamin.woodruff@vercel.com>

Mostly to proof one particular runtime check is unnecessary.

…currently used version (#70635)

Updates some API's so that they aren't calling unsupported Node.js API's while in the Edge runtime.

This auto-generated PR updates font data with latest available

This enhances the current parsing completed by Next.js of configuration from app segments. Previously a collection of fragile checks was used to parse the different segment configuration options which performed no validation on the inputs. This uses the `zod` library (which we already use internally) to perform validation on the configuration exported. A followup PR #70480 will add more verbose error logging around the validation errors.

@samcx

…70392) This PR updates the `environment-variables` example to use the App Router. Here are the changes that have been made: - Created an `app` folder and added `page.tsx` file. - Added `layout.tsx` file - Updated the `readme.md` file. - Updated the `package.json` file. cc : @samcx --------- Co-authored-by: samcx <sam@vercel.com>

The test assumed a certain path for chunks. Changed it to get the files from the served page, making sure that regardless of chunking it's checking the right files for the requested route.

Closes PACK-3244 Closes #69562 Await the module in both environments (SSR/browser), if it's async in at least one of them. We can't and don't want to make the browser module async (artifically) if the SSR module is async (due to ESM externals). The only concern regarding `async` not always being true in the manifest was that we don't want to await in non TLA cases (e.g. CJS exporting a promise, etc...). But the SSR module being ESM with TLA and the browser module being CJS with a Promise export is exceedingly unlikely.

We now ask for all input in a single phase at the beginning followed by a single phase of long running tasks that processes this input. Interleaving is unintuitive and may leave the process hanging if people tab out when the install takes more than a few seconds.

#70363) Co-authored-by: マルコメ <akio.muto@bnt.benextgroup.jp> Co-authored-by: Jiachi Liu <inbox@huozhi.im>

…70667) In a pathname for an intercepting route, a dynamic path param might occur multiple types, e.g. `'/[locale]/example/(...)[locale]/intercepted'` (for `[locale]/example/@modal/(...)[locale]/intercepted/page.tsx`). We need to make sure that each occurence is replaced with the actual value during interpolation. The handling of such pathnames is already done correctly in the Node.js runtime, but not in the Edge runtime. fixes #70654

…70650) By default we are storing the seeded prefetch entry (from the SSR render) as an "auto" prefetch. The prefetch cache is used because every navigation checks against the prefetch cache to determine if it has the necessary data to render the requested segment(s). We have a router heuristic that will re-fetch a page that's already in the prefetch cache if the one that is stored is an "auto" prefetch, and the newly requested prefetch is a "full" prefetch. This is because the assumption is the "auto" prefetch would contain partial data (potentially only `loading.js` data) while the "full" prefetch has everything, so we'd want to replace the cache entry with the most up to date information. Currently when we seed the prefetch cache with the initially SSRed page, we set a cache status of "auto". This is because a "full" prefetch has staleTime implications: a full prefetch will be client cached for 5 minutes by default (the `static` staleTime), and since we have no prefetch intent during SSR, we should fallback to the automatic caching heuristics to avoid caching a page longer than what was intended. However, this will trigger the above mentioned logic to switch to a "full" prefetch if the page you're currently on has a link to itself, with `prefetch={true}`, resulting in a wasted request. This refactors the logic responsible for switching a prefetch entry to a "full" prefetch only once we confirm the response payload from the existing cache entry wasn't a response that started rendering from the root. If we started rendering from the root, we know that we have the full data already, so it'd be wasteful to fetch again. Fixes #70535

### What? The normal file watcher doesn't work inside a docker container, the workaround is to enable a polling file watcher, which was supported in webpack but not turbopack so far. This PR adds support for a polling file watcher to turbopack and a `next.config.js` option to configure the polling file watcher for both webpack and turbopack. Unfortunately, the rust file watcher seems to be a lot slower than the poll interval. Closes PACK-3206 Fixes #68255

## Description [with-google-analytics example](https://github.com/vercel/next.js/tree/canary/examples/with-google-analytics) was updated for App Router at #66021. So remove an old pages path. ### 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 --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>

# Summary Add `aria-label` to static indicator button for accessibility ## Description Some browser reports `Buttons must have discernible text: Element has no title attribute` for the static indicator button. Then insert `aria-label="Hide static indicator"` s-ref: [Buttons must have discernible text](https://dequeuniversity.com/rules/axe/4.4/button-name?application=axeAPI) Co-authored-by: JJ Kasper <jj@jjsweb.site>

This provides information to the initial SSR render that the client leverages when seeding the prefetch cache, to determine if a page was a fully static prerender. The side effect of not doing this is that if we seeded a static page during SSR, and then navigated to it, the router would make a request for data that it didn't need. In other words, it didn't honor the static staletime, like other navigations would.

This adds support for `images.localPatterns` config to allow specific local images to be optimized and (more importantly) block anything that doesn't match a pattern.

) ## Why? There is no mention of how App Router uses hover for prefetching (`null`, and `true`). There is only a mention of hover for the `false` state. --------- Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>

As previously discussed we've talked about ensuring this `stale-while-revalidate` can be consumed by CDNs by default which means we need to have a default SWR delta so this defaults to one year although it can still be customized via the `swrDelta` config. One gotcha with this is users when testing locally with `next start` or there is no CDN consuming the header browsers will consume the header. This gotcha is worth the change as it can be configured and most proper setups should be behind a CDN to consume this header.

This PR adds support for using Form with pages dir. The functionality is a bit limited: - in pages dir, Form doesn't prefetch, because there's no notion of an instant loading state that we could prefetch - No support for server actions - pending indicators from `useFormStatus` do not work while navigating to the target page (planning to address this in #70681) But other than those things, Form should work. Both of these patterns are supported: - `<Form action="/foo/bar">` - `<Form action={clientAction}>` (if using a react version with `useActionState`)

# Summary Remove redundant html element and css. Add alt text to images. Both old and new README.md have the same appearance. ## Description I changed some parts. ### 1. Insert `align="center"` into only top `<div>` tag The all of logo, title, and badges are center. Then it doesn't need to call at every element. ### 2. Move `<h1>` tag outside `<a>` tag The title doesn't have link even if inside `<a>` tag when it's wrapped heading element. So put it out for the readability. ### 3. Use image alt text instead of aria-label Alt text is displayed on the page if the images can't be loaded. That's why I prefer alt text to aria-label. In addition, the screen reader still reads the same words after updating. ### 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 x-ref: [\<img>: The Image Embed element](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img) | mdn web docs --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>

### What? * round chunk item sizes to cause less changes to chunking * pick individual values from compile time info to avoid invalidating on change * pick next config keys for more granular caching * split completions into a tree --------- Co-authored-by: Niklas Mischkulnig <4586894+mischnic@users.noreply.github.com>

Fixes some broken tests from #68333. They were skipped, but still crash in `start` mode, because they try to use `useActionState` and crash during prerendering (because 18 doesn't have that). We turn those pages into noops instead -- the tests that use them are skipped anyway.

#70705)

viewport will never be streaming because is necessarily blocks important shell time rendering with things like themeColor and viewport size. Most other metadata can be streamed in if we're not serving an agent which doesn't construct a DOM. This change doesn't actually make metadata streaming but it does further separate the two so we can more easily alter the rendering characteristics of metadata without affecting viewport. The approach is to ensure the metadata component creation is in the react-server layer in the server module graph so it can access `React.cache`. then we construct a pair of functions that can produce the resolved metadata and viewport values, throwing if there is an encountered error. We suppress these errors in our top level metadata component (MetadataRoot) and and simultaneously expose a ready function which calls these (`React.cache()`'d) functions in the Metadata outlet where any errors will throw. This cleans up the layering quite a bit and makes some runtime error checks unecessary such as ensuring you rendered the MetadataRoot before attempting to determine if the metadata was resolved. The key thing achieved here though is that Metadata and Viewport now resolve in parallel but separately. We avoid double walking the module graph by again making use of `React.cache()`. In the future we can render each of these components differently without affecting each other. This work is motivated more immediately by some error tracking work I will land after this that needs to determine whether viewport or metadata were dynamic independently. There is one semantic difference worth calling out. Previously if you called `notFound()` in `generateMetadata()` or `generateViewport()` both would render the appropriate not found metadata/viewport. In this latest update only the one that called notFound will update to reflect the notFound metadata/viewport. I think fundamentally the approach to handling notFound needs to change here. Really we should be abandoning the render and starting over. This will be doubly important once metadata is streaming. I'm ok with the edge case as is given customizing viewport is not very common and calling notFound from within generateViewport is expected to be an edge case of an edge case. The workaround for now is to call notFound simultaneously from both generateViewport and generateMetadata

This has long been a misnomer since it's not just used for static generation but it's the outer context of all the "Work" we're currently doing. A follow up will merge the other contexts into a "WorkUnitStore".

### What? Small type tweak, asked for in #70443 ### Why? The `alt` prop is required on the call to `getImgProps`, and the implementation, returns it back to the caller, however, the type signature of the return type for `getImgProps`, omits the `alt` prop, which means that users have to manually apply the `alt` prop. That is to say, that in this example, tweaked from the docs: ```jsx import { getImageProps } from 'next/image' export default function Page() { const common = { alt: 'Theme Example', width: 800, height: 400 } const { props: { srcSet: dark }, } = getImageProps({ ...common, src: '/dark.png' }) const { props: { srcSet: light, ...rest }, } = getImageProps({ ...common, src: '/light.png' }) return ( <picture> <source media="(prefers-color-scheme: dark)" srcSet={dark} /> <source media="(prefers-color-scheme: light)" srcSet={light} /> {/* the alt prop is here, but as far as TypeScript is concerned, it is not */} <SomeCustomImageComponent {...rest} /> </picture> ) } ``` So users have to do: ```jsx <SomeCustomImageComponent {...rest} alt={common.alt} /> ``` See more at, #70443 ### How? Remove `alt` from the Omit union. ```tsx export type ImgProps = Omit<ImageProps, 'src' | 'alt' | 'loader'> & { /* other stuff */ } ``` Fixes #70443

…mages-manifest.json` (#70730) Since `images.localPatterns` config can be undefined, we need to support that when emitting `images-manifest.json`. - When `undefined`, all local images are allowed - When `[]`, no local images are allowed Note this is different than `remotePatterns` since it treats `undefined` and `[]` the same (the default being no remote images are allowed).

The warnings are fixed by callsite not by something changing an abstraction on top of it. That's at least what the codemod assumes. Basically each warning is now mapped to a change the codemod should've made but didn't to avoid false-positives (e.g. propagating `async` across module boundaries). For browser specific access we don't dedupe since we have no `React.cache`

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[pull] canary from vercel:canary #122

[pull] canary from vercel:canary #122

Commits on Sep 17, 2024

Commits on Sep 18, 2024

Commits on Sep 19, 2024

Commits on Sep 20, 2024

Commits on Sep 22, 2024

Commits on Sep 23, 2024

Commits on Sep 24, 2024

Commits on Sep 25, 2024

Commits on Sep 26, 2024

Commits on Sep 27, 2024

Commits on Sep 28, 2024

Commits on Sep 30, 2024

Commits on Oct 1, 2024

Commits on Oct 2, 2024

[pull] canary from vercel:canary #122

Are you sure you want to change the base?

[pull] canary from vercel:canary #122

Commits on Sep 17, 2024

Commits on Sep 18, 2024

Commits on Sep 19, 2024

Commits on Sep 20, 2024

Commits on Sep 22, 2024

Commits on Sep 23, 2024

Commits on Sep 24, 2024

Commits on Sep 25, 2024

Commits on Sep 26, 2024

Commits on Sep 27, 2024

Commits on Sep 28, 2024

Commits on Sep 30, 2024

Commits on Oct 1, 2024

Commits on Oct 2, 2024