Fixes https://github.com/vercel/next.js/issues/54240
The Link component in App Router is not respecting `scroll-behavior: smooth` when only the hash changes.
It appears to be caused by `focusAndScrollRef.onlyHashChange = false` being set before `handleSmoothScroll` is called, causing `htmlElement.style.scrollBehavior` to be overridden to `auto` before `scrollIntoView` is called.
Moving `focusAndScrollRef.onlyHashChange = false` to after `handleSmoothScroll` invocation resolves the issue.
This fixes the compilation of `export { action as renamed }` syntax. Previously it's compiled as `export var action = ...` and with this fix, it will be `export var renamed = ...`.
Closes#54229.
Image Optimization API currently does not work if a custom loaderFile is specified in next.config.js, even if loader is explicitly set to 'default', because it is currently being overridden to 'custom' simply because a loaderFile is specified. This is unnecessary and causing the Image Optimization API routes not to be initialized since the change to the config happens before the routes are initialized.
[Sandbox Reproduction](https://codesandbox.io/p/sandbox/purple-pine-t7hhgl?file=%2Fimage-loader.js%3A8%2C1)
- Fixes#53415
For group routes, unlike normal routes, the root layout is located in the "group"'s segment instead of root layer.
To make it also able to leverage the default not found error component as root not found component, we need to determine if we're in the root group segment in the loader tree, and add the not-found boundary for it.
If you compre the loader tree visually they will look like this:
Normal route tree structure
```
['',
{ children: [segment, {...}, {...}]},
{ layout: ..., 'not-found': ... }
]
```
Group routes
```
[''
{ children: ['(group)', {...}, { layout, 'not-found': ... }]}
{}
]
```
Comparing to normal case, we go 1 layer down in the tree for group routes, then insert the not-found boundary there
Fixes#52255
Closes NEXT-1532
This PR removes our client module reference proxy implementation to directly use the one from the upstream Flight server, as it's added here: https://github.com/facebook/react/pull/27033.
Also updated the server reference creation code a bit to use `defineProperties` - we can't switch to the upstream `registerServerReference` API yet as our Server Actions compiler needs to change a bit to adapt that API since we might have existing `bound` and/or `originalAction` provided.
Closes#53732. Closes#52929.
When using the statically typed routes feature, we might have code like:
```ts
export function Card<T extends string>({ href }: { href: Route<T> | URL })...
export function Card<T extends string>({ href }: LinkProps<T>)...
```
To statically check `<Card href={...}>` and make sure it's `href` is an existing route. However, in certain cases these route types are not generated (e.g. running `tsc` directly w/o a `next dev` or `next build`), which results in TS errors.
This PR adds stub generics to `Route` and `LinkProps` so even if that plugin isn't executed, these types will not block type checking.
### What?
When running Next in standalone mode, `process.env` is not made
available to the render workers, making it impossible to access
environment variables that aren't provided in `.env` files.
### Why?
`initialEnv` is undefined in `createWorkers` when the server is started
in standalone mode.
### How?
This initializes the workers with `process.env` in case `initialEnv` is
unavailable, similar to the behavior of `loadEnvConfig()`
Closes NEXT-1508
Fixes#53367
Follow up to https://github.com/vercel/next.js/pull/54081 -- this was
restoring the router tree improperly causing an error on bfcache hits
Had to override some default behaviors to prevent `forward` / `back` in
playwright from hanging indefinitely since no load event is firing in
these cases
Fixes#54184
Closes NEXT-1528
Fixes#52365
In #52275 that eslint config changed to a fixed canary version to leverage the improvement of `react-hooks` eslint plugin but breaks the installation when 3rd party packages having strict matching for certain version of eslint plugin.
This PR allows both previous version and the canary version be present.
Fixes#54174
We should only add default not-found boundary to loader tree components for root layout. It was accidently added for children routes before
### What?
Strip the relative path prefix (`_next/`) when generating the `PageLoaderAsset`. This is necessary because the page loader will internally use `__turbopack_load__`, which prepends the prefix back onto the path.
### Why?
Without this, we'd try loading `_next/_next/path/to/file.js`, because we'd prepend the prefix onto a path that already contains it.
### How?
When generating the page loader asset, we "proxy" the `OutputAsset` onto a path which has the prefix removed.
~~Depends on https://github.com/vercel/turbo/pull/5717~~
Closes WEB-1377
For edge-runtime we always bundle, and all the mapping of internal ESM files are configured in webpack. Adding a new alias of "next/dist/build" so we don't have to manually check the mapping path for module proxy
Reverts vercel/next.js#53578
This PR (#53578) will break client components test, revert it for now.
Can repro by adding `"use client"` to `app/page.tsx` in `test/production/jest/server-only.test.ts`
```
FAIL app/page.test.jsx
● Test suite failed to run·
Cannot find module 'private-next-rsc-mod-ref-proxy' from 'app/page.jsx'·
Require stack:
```
This:
- Adds a simple, generic tracer in the client that can be subscribed to in order to report spans
- Reports client spans through the HMR socket in the dev server
- Receives these spans and includes them in `.next/trace`
Closes WEB-1387
### What?
~The `setTimeout(() => {}, 0)` was used in place of `setImmediate` due to lack of support in the Edge Runtime. This is no longer a problem.~ Not working like I expected.
`ReadableStream.tee` should be widely supported as well as of [Node 16.5](https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream/tee#browser_compatibility)
### Why?
Use the platform!
### How?
Use the built-in `ReadableStream.tee()`
Note: depends on next Turbopack publish
https://github.com/vercel/turbo/pull/5487 exports a reusable `handle_issues` function for reporting issues and erroring when failing issues are encountered.
This uses it for `next build` with a failing severity level of error.
### What?
When cloning a `Request` with `NextRequest` the second argument needs to take precedence over the `Headers` set on the original request.
### Why?
Follow-up of #53157
I checked the `Request` spec https://fetch.spec.whatwg.org/#request-class and following the order of execution, `init.headers` should indeed override the headers if the first param was `Request`.
I verified this in the browser too:
```js
const req1 = new Request("http://n", {headers: {"x-header": "foo"}})
const req2 = new Request(req1, {headers: {"x-header-2": "bar"}})
Object.fromEntries(req2.headers) // {x-header-2: "bar"}
```
So we should match `NextRequest` with this behavior.
### How?
Pass the `init` to `super` when cloning the request.
Closes NEXT-1521
Fixes#54094
When an mpa navigation takes place, we currently push the user to the new route and suspend the page indefinitely (x-ref: #49058). When navigating back, if the browser opts into using the [bfcache](https://web.dev/bfcache/), it will remain suspended and `pushRef.mpaNavigation` will be true. This means that anything that would cause the component to re-render will trigger the mpa navigation again (such as hovering over another `Link`, as reported in #53347)
This PR checks to see if bfcache is being used by observing `PageTransitionEvent.persisted` and if so, resets the router state to clear out `pushRef`.
Closes NEXT-1511
Fixes#53347
This ensures that corepack uses the correct package manager and version for the tmpdir install as it does for the rest of the repo. It reads the value from the root `package.json`.
Closes WEB-1401
### What & Why
Previously when rendering the root `/_not-found` in production, we'll always override the parallel routes component children with not-found component, this will break the navigation in build mode from root 404 `/_not-found` path.
### How
The new solution is to change the root `/_not-found` rendering strategy. Previously the loader tree of `/_not-found` look like this
```js
['',
{
children: ['not-found', {}, {}]
},
{ layout: ..., 'not-found': ...}
]
```
it's not a pretty valid tree, which could lead to problems during rendering.
New solution is to change the children to render a page, but the page content is `not-found.js` component. The new tree of root not-found will look like
```js
['',
{
children: ['__PAGE__', {}, {
page: ... // same as root 'not-found'
}]
},
{ layout: ..., 'not-found': ...}
]
```
This change could fix the navigation on the root not-found page.
Fixes#52264
