## Background
Currently route handlers will be attempted to statically generate the
same as normal pages in app router. If a route handler accessed dynamic
data such as `cookies()`, `headers()`, `req.url`, or similar we would
bail from this static generation but this didn't handle the case where
you would do data fetching via a non-fetch based library e.g. `redis` or
even using `Date.now()` or `Math.random()` so users would expect these
to be run every request like normal API endpoints but they would be
static so wouldn't be executed again after a build.
## New Behavior
As discussed this disable the default static generation handling for
route handlers as we've seen this confuse our users since in most cases
when creating a route handler you are handling dynamic workloads. This
doesn't remove the ability to static generate route handlers though as
you can still manually specify:
If you specify `export const revalidate = 1` we will still bail if
dynamic data is accessed to prevent accidental `revalidate` configuring
but this can be avoided via `force-static` being used as well.
```js
export const dynamic = 'force-static'
// or
export const dynamic = 'error'
// or
export const revalidate = false
// or
export const revalidate = 1 // value great than 0
// or
export const generateStaticParams() {}
```
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
This PR addresses an issue where the `dev` script in `package.json` was
not correctly updated to use the `--turbo` option when specified. The
changes ensure that the `dev` script is set to `next dev --turbo` if the
`turbo` option is enabled.
### Changes:
1. **Function Modification**:
- Updated the `modifyPackageJson` function to include a check for the
`turbo` parameter.
- If `turbo` is true, the `dev` script in `package.json` is set to `next
dev --turbo`.
- If `turbo` is false, the `dev` script remains `next dev`.
2. **Integration in App Creation**:
- Integrated the `modifyPackageJson` function into the app creation
process to ensure the `dev` script is correctly set based on the `turbo`
parameter.
### Testing:
- Verified that the `dev` script in `package.json` is correctly updated
to `next dev --turbo` when the `turbo` option is enabled.
- Ensured that the `dev` script remains `next dev` when the `turbo`
option is not enabled.
### Related Issues:
- Fixes#65924
### Notes:
- This change ensures that developers opting to use Turbopack for
development will have the correct script set up automatically.
---------
Signed-off-by: Arindam Majumder <arindammajumder2020@gmail.com>
Co-authored-by: Lee Robinson <me@leerob.io>
Co-authored-by: devjiwonchoi <devjiwonchoi@gmail.com>
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
Co-authored-by: Sam Ko <sam@vercel.com>
Currently `OPTIONS` requests to page handlers (eg `pages/foo.tsx` or
`app/foo/page.tsx`) will respond as though it's handling a `GET`
request. There should be no reason for these routes to handle `OPTIONS`
requests as the only valid option is `GET`.
We do not need to special-case actions here because those will always be
invoked from the same origin as the canonical browser URL.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
Closes NEXT-3305
## Background
Historically during prerendering we have waiting until all paths have
been attempted before we exit the process and fail the build. This is
nice if you want to collect all potential errors to address them at the
same time although this has the drawback of slowing down builds if
things are timing out or if the same error is occurring across numerous
paths.
## New Behavior
This changes our default behavior to immediately exit when the first
error occurs during prerendering so that builds don't stall out from
timeout errors or from the same error occurring across numerous paths.
This will help from holding up CI or similar un-necessarily.
If users want to opt-in to the previous behavior the flag is still
present under `experimental.prerenderEarlyExit`.
cc @icyJoseph @ztanner
NOTE: The canary release
[`v14.1.1-canary.51`](https://github.com/vercel/next.js/releases/tag/v14.1.1-canary.51)
and below work as expected.
### Why?
Introduced from #61535, the initial prefetch cache is set based on the
`location.pathname`.
When a page is loaded WITH the search param, the cache key does not
contain information of the search param.
The issue is when on a dynamic page reading the `searchParams` value,
the value doesn't change if navigated as:
```
/?q=foo --> /
```
The prefetch cache hits, not re-rendering, and the `searchParams` value
is not passed properly.
### How?
For the prefetch cache, add the `location.search` as well.
Since `createPrefetchCacheKey` uses
[`createHrefFromUrl`](https://github.com/vercel/next.js/blob/canary/packages/next/src/client/components/router-reducer/create-href-from-url.ts)
which includes `location.search`, I'm expecting the change won't affect
current cache key behavior.
Fixes#64170Fixes#65030
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
Adds support for nested `unstable_after()`.
This pattern previously threw a "Not supported yet" error, but works
now:
```js
function MyComponent() {
after(() => asyncWork());
return <div>...</div>
}
async function asyncWork() {
after(() => { /* look ma, nesting!*/ })
// more stuff...
}
```
### Implementation notes
Switched `AfterContext` to use a proper promise queue
([`p-queue`](https://www.npmjs.com/package/p-queue)) instead of plain a
callback array to support adding more callbacks as we execute (i.e. from
nested `after`s). Used a package because I didn't want to reinvent the
wheel here.
As a nice bonus, `p-queue` lets us limit the concurrency of running
tasks if we're worried about resource consumption. **This PR doesn't do
that**, but it's very easy to add. That could be controlled via
`process.env.NEXT_AFTER_MAX_CONCURRENT_TASKS`, a next.config.js option
(`unstable_after: { maxConcurrentTasks: 5 }`), or something like that.
### What?
Upgrades sharp to the latest version and relies on more of its default
settings (if the default settings are unsuitable, we should consider
improving these for all users in sharp itself).
- The `sequentialRead` setting is now managed for you based on each
input image and the operations to be applied to it.
- The concurrency detection is more accurate than `os.cpus()` as it now
inspects things like CPU set/affinity as well as the memory allocator.
- The (mostly archaic) concept of chroma subsampling is not required for
AVIF output. Using full chroma should improve the quality of red/orange
edges, as well as slightly reducing file size as it allows greater use
of AV1 chroma-from-luma prediction.
In addition, this PR also enables the use of mozjpeg features such as
trellis quantisation to produce smaller file sizes. The use of `mozjpeg:
true` infers `progressive: true`. This aligns JPEG output behaviour with
the previously-used squoosh, which always used mozjpeg.
/cc @styfle
Implements `unstable_after`, which lets the user schedule work to be
executed after the response is finished.
### Implementation notes
- `unstable_after()` is a dynamic function (bypassable only with `export
dynamic = "force-static"`)
- Usable in: server components (including `generateMetadata`), actions,
route handlers, middleware
- It is meant to run its callbacks even if a response didn't complete
successfully (thrown error) or called `notFound()`/`redirect()`
- Currently gated behind a `experimental.after` feature flag, because it
touches many runtime bits (including a React monkeypatch...)
- The state for `unstable_after()` in a given request lives in
`requestAsyncStorage` (added via `RequestAsyncStorageWrapper`)
- the implementation is based around two functions that we inject via
`renderOpts`:
- `waitUntil(promise)` - keep a function invocation alive until a
promise settles. it is provided as a platform primitive in serverless
contexts, and a noop in `next start`
- for serverless (nodejs), Next.js will attempt to get `waitUntil` from
`globalThis[Symbol.for('@next/request-context')].get().waitUntil`. This
should be considered unstable for now. See
`packages/next/src/server/after/wait-until-builtin.ts` for details.
- `onClose(callback)` **[NEW]** - run something when a response is done.
basically `res.on('close', callback)`, but also implemented for Web APIs
- unfortunately, for Web, this requires some potentially expensive
tricks - see `packages/next/src/server/web/web-on-close.ts`
the 'should show an experimental warning' test in
`react-compiler-test.ts` has been randomly flaking for me:
```
Expected substring: "Experiments (use with caution)"
Received string: " ⚠ `experimental.ppr` has been defaulted to `true` because `__NEXT_EXPERIMENTAL_PPR` was set to `true` during testing.
⚠ `experimental.ppr` has been defaulted to `true` because `__NEXT_EXPERIMENTAL_PPR` was set to `true` during testing.
▲ Next.js 14.3.0-canary.69
- Local: http://localhost:40095
"
```
when the actual CLI output is:
```
⚠ `experimental.ppr` has been defaulted to `true` because `__NEXT_EXPERIMENTAL_PPR` was set to `true` during testing.
⚠ `experimental.ppr` has been defaulted to `true` because `__NEXT_EXPERIMENTAL_PPR` was set to `true` during testing.
▲ Next.js 14.3.0-canary.69
- Local: http://localhost:40095
- Experiments (use with caution):
· reactCompiler
```
which indicates that we're reading the CLI output too early
### What
Error when users installing react@18 and requires higher version
### Why
The architecture now already requires to have `react@beta` or
`react@rc`. Especially where we need to load `react-server` condition of
react, which is erroring now in react 18.
- Ensure React Compiler runs on first-party code in Turbopack (Excludes
node_modules, but also fully skips running Babel on node_modules)
- Ensure React Compiler runs on first-party code in Webpack (Excludes
node_modules, but also fully skips running Babel on node_modules)
- Ensure React Compiler only runs on browser code -- Per React team
recommendation, it only optimizes browser-facing code currently.
- Ensure React Compiler runs on Pages Router in Webpack -- Was already
the case for Turbopack.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
### What
Fix a bug introduced in #65694 , use app-page runtime for app router
layers
### Why
This is basically reverted the route context picking up logic we had
before.
During the test we found the error thrown
> Module not found: shared-runtime module router-context cannot be used
in rsc layer
Which is caused by a `next/router` imports in rsc page. Decided to
revert to what it was before as the most safe way to load share module
contexts.
It's caused by `next-contentlayer` usage that they're using
`next/router` in server component MDX, but we cannot lint error that
from node_modules. (We actually can, but disabled that due to various
mis-usage of server/client hooks we had before)
In `test/production/graceful-shutdown/index.test.ts`, 2 tests cases are
always failing, disabled them for now to investigate later.
In
`test/e2e/app-dir/actions-allowed-origins/app-action-allowed-origins.test.ts`,
the hard-coded `port` was used sometimes already been used, so we change
that to a "random" port which can help find an available port instead of
`'0'`.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What
This PR exposes new experimental configuration for next.js,
`experimental.reactCompiler`. Under the hood, this option configures to
use new experimental react compiler
(https://react.dev/learn/react-compiler#). `reactCompiler` value can be
either boolean or an object contains partial set of compiler itself's
configuration option.
For the webpack and turbopack both it is enabled by adding a babel
plugin for the react compiler. If user have an existing .babelrc, plugin
will be appended to the config. Otherwise, swc will still kicks in (for
webpack) or turbopack for the general transform but only compiler babel
plugin will run via babel.
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
This PR sets the upstream image timeout to 7 seconds so its not
unbounded (P99 is about 3 to 4 seconds).
We also set the sharp timeout to 7 seconds (P99 is about 2 seconds
although it depends on CPU).
This means an image could take at most 14 seconds to fetch and optimize.
When we provide the `set-cookie` string in `x-middleware-set-cookie`, we
need to ensure that multiple values are properly delimited.
We also make sure the cookies that get passed into `RequestCookies`
aren't in `ResponseCookie` form, to prevent something like `Path=/` from
being part of `cookies()`.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
### What
Let `middleware` and `instrumentation` apply `react-server` exports
condition names first. When bundle the react and react-dom, bundle the
installed version instead of the built-in version.
Renamed "app" group for webpack layers to "bundled", which indicates it
will bundle all the dependencies.
### Why
Middleware and instrument are sort of isolated from app router and pages
router, if they're using react should pick up from the installed
version. Since they're in server layer so they only need to bundle the
`react-server` conditions.
x-ref: [slack
thread](https://vercel.slack.com/archives/C046HAU4H7F/p1715790385748169)
This PR ensures that any arbitrary binary data can be passed across the
RSC boundary, especially when inlined in HTML. While the Flight payloads
in RSC requests (`text/x-component`) already work, it's a different case
when we inline them directly in HTML as that's required to be a valid
string in UTF-8.
So instead of always inlining the UTF-8 decoded chunk (`new
TextDecoder('utf-8')`), we fallback non-decodable chunks to base64 and
send as a special item in `__next_f` so we can safely change it back to
a binary typed array.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This PR introduces a **breaking change** that returns a 400 error if the
Image Optimization API is given a protocol-relative URL.
The Image Optimization API currently checks whether the given image URL
is relative by checking `url.startsWith('/')`. This means that
protocol-relative URLs, such as `//example.com`, pass the check and are
treated as relative. They in turn skip any kind of validation provided
when matching against `remotePatterns` and are passed back to the
optimation logic as a relative URL.
My knowledge of the stack stops there, but in our case at GitBook it led
to a nasty attack where non-GitBook content could be served over this
URL: https://docs.gitbook.com/_next/image?url=//example.com&w=1200&q=100
- even though we have configured `remotePatterns` to protect against it.
I originally went into the problem wanting to handle the URL properly
(treating it as an absolute URL and potentially using the protocol of
the Optimization API itself as the relative protocol), but after seeing
the code in
https://github.com/vercel/next.js/blob/canary/packages/next/src/client/legacy/image.tsx#L135
and
https://github.com/vercel/next.js/blob/canary/packages/next/src/shared/lib/image-loader.ts#L26
it feels that protocol-relative URLs are just not really supported
anywhere. My understanding is that very few uses of `next/image` will be
allowed to use protocol-relative URLs, so the impact of this breaking
change should be quite low? If others disagree I am happy to modify and
to use the protocol of the request as a stand-in for the relative
protocol.
---------
Co-authored-by: Steven <steven@ceriously.com>
### What
Disable auto polyfill for process in edge runtime.
### Why
React uses process.emit behind a typeof guard now. This leads to process
being bundled and process.emit being called which triggers build
warnings since we stub process APIs since they're not supported in Edge
runtime.
There's condition like `"object" === typeof process && "function" ===
typeof process.emit` in the react build now where the 2nd condition is
falsy. Stop polyfilling to skip that condition since it's mainly for
Node.js runtime
Related to #65692
### What?
This PR adds an experimental option `clientTraceMetadata` that will use
the existing OpenTelemetry functionality to propagate conventional
OpenTelemetry trace information to the client.
The propagation metadata is propagated to the client via meta tags,
having a `name` and a `content` attribute containing the value of the
tracing value:
```html
<html>
<head>
<meta name="baggage" content="key1=val1,key2=val2">
<meta name="traceparent" content="00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01">
<meta name="custom" content="foobar">
</head>
</html>
```
The implementation adheres to OpenTelemetry as much as possible,
treating the meta tags as if they were tracing headers on outgoing
requests. The `clientTraceMetadata` will contain the keys of the
metadata that're going to injected for tracing purpose.
### Why?
Telemetry providers usually want to provide visibility across the entire
stack, meaning it is useful for users to be able to associate, for
example, web vitals on the client, with a span tree on the server. In
order to be able to correlate tracing events from the front- and
backend, it is necessary to share something like a trace ID or similar,
that the telemetry providers can pick up and stitch back together to
create a trace.
### How?
The tracer was extended with a method `getTracePropagationData()` that
returns the propagation data on the currently active OpenTelemetry
context.
We are using `makeGetServerInsertedHTML()` to inject the meta tags into
the HTML head for dynamic requests.
The meta tags are generated through using the newly added
`getTracePropagationData()` method on the tracer.
It is important to mention that **the trace information should only be
propagated for the initial loading of the page, including hard
navigations**. Any subsequent operations should not propagate trace data
from the server to the client, as the client generally is the root of
the trace. The exception is initial pageloads, since while the request
starts on the client, no JS has had the opportunity to run yet, meaning
there is no trace propagation on the client before the server hasn't
responded.
Situations that we do not want tracing information to be propagated from
the server to the client:
- _Prefetch requests._ Prefetches generally start on the client and are
already instrumented.
- _Any sort of static precomputation, including PPR._ If we include
trace information in static pages, it means that all clients that will
land on the static page will be part of the "precomputation" trace. This
would lead to gigantic traces with a ton of unrelated data that is not
useful. The special case is dev mode where it is likely fine to
propagate trace information, even for static content, since it is
usually not actually static in dev mode.
- _Clientside (soft) navigations._ Navigations start on the client and
are usually already instrumented.
### Alternatives considered
An implementation that purely lives in user-land could have been
implemented with `useServerInsertedHTML()`, however, that implementation
would be cumbersome for users to set up, since the implementation of
tracing would have to happen in a) the instrumentation hook, b) in a
client-component that is used in a top-level layout.
### Related issues/discussions
- https://github.com/vercel/next.js/issues/47660
- https://github.com/vercel/next.js/discussions/62353 (Could be used as
an alternative to the server-timing header)
- https://github.com/getsentry/sentry-javascript/issues/9571
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
### Fixing a bug
fixes#65580
### What?
#65580
### Why?
Currently, afterInteractive is given as the default strategy prop, but
afterInteractive is not set for the child retrieved through
React.Children, and it is an empty prop and is not added to the script
loader, so the script is not executed.
### How?
Added item to script loader when `child.props.strategy` is undefined.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
-->
### What?
Adding support for supporting a custom fontFamily name when using
next/font
### Why?
By default, next/font hashes the font name when generating css to
achieve proper scoping.
However, that makes it impossible to use next/font with 3rd party
libraries that provide CSS with pre-defined font names.
### How?
To solve this, I've added a new argument to the next/font function call
– `usedFontFamilyName`.
It allows developers to pick the fontFamily name that is going to be
used in the CSS output instead of the default one and make it work with
vendor CSS files.
```
import { Inter } from "next/font/google";
const inter = Inter({
subsets: ["latin"],
fixedFontFamily: "Inter",
});
```
Fixes [#43452](https://github.com/vercel/next.js/discussions/43452)
---
Edit:
I've changed the implementation to use `disabledFontFamilyHashing`
boolean flag which removes the hashing but keeps the original font
family name instead of allowing a custom name
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
BREAKING CHANGE:
Using the built-in image optimization API, the URL is parsed with `new
URL()` constructor which automatically trims spaces.
However, the developer may choose a 3rd party image optimization API via
`loader` or `loaderFile` (or perhaps a deployment platform that has its
own built in loader), so we shouldn't assume the API will parse the URL
in the same way as
[WHATWG](https://url.spec.whatwg.org/#:~:text=If%20input%20contains%20any%20leading%20or%20trailing%20C0%20control%20or%20space%2C%20invalid%2DURL%2Dunit%20validation%20error.).
While we could trim on the client, its probably best to fail fast and
let the developer make a conscience decision if a trailing space should
be removed or remain (by explicitly using `%20`).
### What
Remove `swcMinify` related branches as the option is deprecated and it's
always enabled
* Remove the related branches for checking `config.swcMinify`
* Remove the related telemetry about `swcMinify`
### What
Remove `missingSuspenseWithCSRBailout` and always treate the conditions
where it was used as `true`.
### Why
This was an intended behavior introduced in 14.1, which requires users
to always add suspense boundaries if it's using any hook that could bail
out to client rendering. `missingSuspenseWithCSRBailout` as `true` was
the default behavior and you could disable it with
`missingSuspenseWithCSRBailout: false` in next config. Now after the
removal you will not be able to opt-out it.
Previously we only display the warning when it's a new key format
`<object>.<property>`, we should display all cases to help users
understand where the new key is moved to
x-ref: https://x.com/huozhi/status/1789335665252921381
### What
Reland #57448 , add react-server condition resolving and apply
server-only rules to middleware
Closes NEXT-1653
Closes NEXT-3333
### Why
Middleware as the pre-routing layer that is indended to be light-weight.
Since it's on edge runtime and only run on server but not on client, it
doesn't need to include the client react bundles. Hence we apply
`react-server` export condition, that if users import React we can only
bundle server required APIs and if users use React client hooks we can
error.
Adding some tests based on this Twitter thread:
https://twitter.com/NicoloRibaudo/status/1788919867002785984
Here's what I found:
- Added a new test suite testing for:
- Private fields
- Turbopack: Works
- Webpack: Works on latest
- Earlier versions of Next.js with Webpack you'd see an error failing to
parse coming from `acorn`, which webpack uses internally.
- Verified it's not failing on `next@latest` in [this
sandbox](https://codesandbox.io/p/devbox/brave-mcnulty-gszh3q?file=%2Fapp%2Fpage.tsx%3A59%2C32).
- `import` `with { type: 'json' }`
- Turbopack: Works
- Webpack: Works
- `export as` I.e. `export { x as abc }`
- Turbopack: Works
- Webpack: Works
- RegExp with `/v`
- Node.js: ⚠️ Not enabled in the test because Node.js does not support
it currently in 18.x which we run tests against.
- Turbopack: Works
- Webpack: Fails in Webpack currently on `acorn` parsing the JavaScript
## Results
In case you want to play with the test here's a codesandbox with the
same code that is in the tests:
- `next@latest`: https://codesandbox.io/p/devbox/brave-mcnulty-gszh3q
- Url: https://gszh3q-3000.csb.app/
Dev: Webpack
```
PASS test/e2e/app-dir/ecmascript-features/ecmascript-features.test.ts
ecmascript-features
✓ should work using cheerio
✓ should work using browser
```
Build: Webpack
```
PASS test/e2e/app-dir/ecmascript-features/ecmascript-features.test.ts
ecmascript-features
✓ should work using cheerio
✓ should work using browser
```
Dev: Turbopack
```
PASS test/e2e/app-dir/ecmascript-features/ecmascript-features.test.ts
ecmascript-features
✓ should work using cheerio
✓ should work using browser
```
Build: Turbopack
```
PASS test/e2e/app-dir/ecmascript-features/ecmascript-features.test.ts
ecmascript-features
✓ should work using cheerio
✓ should work using browser
```
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
### BREAKING CHANGE
This changes the behavior of the default image `loader` so that
[`Content-Disposition`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition#as_a_response_header_for_the_main_body)
header is now `attachment` for added protection since the API can serve
arbitrary remote images.
The new default value, `attachment`, forces the browser to download the
image when visiting directly. This is particularly important when
`dangerouslyAllowSVG` is true. Most users will not notice the change
since visiting pages won't behave any differently, only visiting images
directly.
Users can switch back to the old behavior by configuring `inline` in
next.config.js
```js
module.exports = {
images: {
contentDispositionType: 'inline',
},
}
Remove font loaders resolving for `@next/font`, users should directly
rely on `next/font`, they're intended to be removed.
Also removed the legacy tests
When a server action performs a redirect, we send an RSC request to the
redirect URL so that everything can be handled in a single roundtrip.
However, we forward the `next-action` header to that request. This means
that the intra-app RSC request will be incorrectly associated with an
action, and any rewrites we do for `next-action` requests (such as the
work in the Next.js builder to ensure actions are routed to streaming
outputs) won't be handled correctly.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
This test was failing with my changes in
https://github.com/vercel/next.js/pull/64932 because it was using the
new Next.js changes, but not the corresponding react-dom changes.
An alternative solution would be to update the react-dom versions to
match those in the rest of the project (19 beta), but I think this is
better overall.
After removing the dependencies, this test works in my branch.
## What
Ensures `nonce` is added to script and link tags Next.js renders.
Additional cases it now handles:
- We already passed `nonce` to the React rendering, though not
consistently on all cases where `renderToStream` is called, I'm
surprised there haven't been more reports of this, but now it will pass
it on all cases where React rendering is called that I could find
- In `get-layer-assets.tsx` we now pass `nonce` to both the `script` and
`link` tags
- When calling `ReactDOM.preload` the nonce was missing as well, ensured
that the nonce is included in that case as well.
Added a test that mimicks the reproduction by adding `next/font` in this
case.
Fixes#64037
Closes PACK-2973
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
## Why?
Adding an `--empty` flag so we can easily create an empty Create Next
App template.
Closes NEXT-3367
---------
Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
### What
Remove the extra `__esModule` and `$$typeof` export for ESM client
module
For a client page reference, it changed on server side in renderer:
Previous: `{ __esModule, $$typeof, default }`
Now: `{ default }`
### Why
The Module object itself appears as a client reference but it can't be
rendered since it's not a real reference. I'm not sure why it was added
but I think the right thing for an ESM module is to not treat the module
itself as a client reference but only the objects inside of it. E.g. the
"default" export. That's what React does upstream for ESM modules.
Closes NEXT-3360
Noticed while doing some testing that this route was broken in this
application. We use some parts of this app to generate statistics - I'm
planning to use more of the routes for benchmarking so I wanted to
ensure it was working.
Closes NEXT-3371
### What
Remove the auto appending `.xml` extension to the sitemap routes when
it's a dynamic route.
### Why
Previously we were adding `.xml` to `/[...paths/]sitemap` routes, but
the bad part is when you use it to generate multiple sitemaps with
`generateSitemaps` in format like `/[...paths/]sitemap.xml/[id]`, which
doesn't look good in url format and it can be inferred as xml with
content-type. Hence we don't need to add `.xml` in the url.
Before this change it could also result into the different url between
dev and prod:
dev: `/sitemap.xml/[id]`
prod: `/sitemap/[id].xml`
Now it's going to be aligned as `/sitemap/[id]`. Users can add extension
flexiblely.
Closes NEXT-3357
This test failed in dev. It has 2 problems:
1. the nanoid only contains named export
2. we should wait for the content changed then check the browser url
```
● app-dir action handling › fetch actions › should handle redirects to routes that provide an
invalid RSC response
expect(received).toBe(expected) // Object.is equality
Expected: "http://localhost:50473/pages-dir"
Received: "http://localhost:50473/client"
891 |
892 | await retry(async () => {
> 893 | expect(await browser.url()).toBe(`${next.url}/pages-dir`)
```
Closes NEXT-3369
### What
Follow up for #64294 where we could preload all the JS and CSS chunks
for `next/dynamic` component.
* Rename `preload-css` component to `preload-chunks` and remove the
filter for css chunks
* Preload JS chunks with `defer`
### Why
Preloading all the async chunks of `next/dynamic` can make rendering
more efficiently when combined with the initial chunks. Since those
chunks are splitted on client but still essential for the page
#### After vs Before
We can see the waterfall starts much earlier for the dynamic chunk
(881.8a0e88...js)
<img width="500"
src="https://github.com/vercel/next.js/assets/4800338/9bab2c32-37c3-4c7a-93e2-3aa43b2ec7c8">
<img width="500"
src="https://github.com/vercel/next.js/assets/4800338/0fba7499-bb69-41c4-ab72-e9952f3d7f68">
### What
* Extract `buildId` and server action encryption key into environment
variables for edge to make code more deterministic
* Fixed the legacy bad env names from #64108
* Always sort `routes` in prerender manifest for consistent output
* Change `environments` to `env` in middleware manifest, confirmed with
@javivelasco this is a fine change without need to bumping the version
### Why
Dynamic variants like `buildId`, SA `encryptionKey` and preview props
are different per build, which results to the non determinstic edge
bundles. Once we extracted them into env vars then the bundles become
deterministic which give us more space for optimization
Closes NEXT-3117
Reverts vercel/next.js#65425
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
### What?
make sure children is first in loader tree to fix head css bug on client
navigation
### Why?
### How?
Fixes PACK-3028
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
### What
Support `esmExternals` working in app router
### Why
`esmExternals` was disabled for app router that most of the packages are
picking up the CJS bundles for externals. This PR enables to resolve the
ESM bundle for external packages.
We have two issues discovered while enabling the flag, any esm external
packages will fail in client page SSR and server action. We fixed them
by changing the below bundling logics:
* When a client page having a async dependency, we can await the page
during in rendering
* When a server action having a async dependency, we changed the server
action entry creation with webpack along with the server client entry
creation together, then webpack can handle the modules async propagation
properly.
Fixes#60756
Closes NEXT-2435
Closes NEXT-2472
Closes NEXT-3225
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
For debugging purposes, it can be useful to set `NODE_ENV=development`
during a `next build`. Currently this value is forced to be production
in Next.js. This PR adds an experimental flag to not force a mode of
`production` when the flag is set.
To use this flag, you'll still need to explicitly set
`NODE_ENV=development`, while also enabling
`nextConfig.experimental.allowDevelopmentBuild`
Closes NEXT-3277
This PR promotes and renames experimental configuration options related
to server bundling:
- `serverComponentsExternalPackages` -> `serverExternalPackages`
- `bundlePagesExternals` -> `bundlePagesRouterDependencies`
Existing docs for `serverComponentsExternalPackages` was changed.
New docs for `bundlePagesRouterDependencies` were added.
Closes NEXT-3332
### What
* Extract `buildId` and server action encryption key into environment
variables for edge to make code more deterministic
* Fixed the legacy bad env names from #64108
* Always sort `routes` in prerender manifest for consistent output
* Change `environments` to `env` in middleware manifest, confirmed with
@javivelasco this is a fine change without need to bumping the version
### Why
Dynamic variants like `buildId`, SA `encryptionKey` and preview props
are different per build, which results to the non determinstic edge
bundles. Once we extracted them into env vars then the bundles become
deterministic which give us more space for optimization
Closes NEXT-3117
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
The tests added in https://github.com/vercel/next.js/pull/46219 were
never correctly testing the headers because `detectContentType()` is
called first and only when we can't detect the type from the response
body do we fallback to the `Content-Type` header.
I also refactored some of the tests because the `ctx: any` type was
causing some tests to not run when testing different configuration
options.
Closes NEXT-3321
Enabling Partial Prerendering (PPR) for an entire application is
ideally, the goal for teams wanting to test out the feature or adopt it
in their applications to get ready for when it becomes the default
rendering pattern. For large applications, with many routes the new
behaviours of old API's may prove a difficult pill to swallow all at
once.
This aims to enable incremental adoption of PPR for pages and routes
that want to support it in a similar way to how existing segment-level
configurations. Segments can now add:
```ts
export const experimental_ppr = true
```
To enable PPR for that segment and those descending segments. Any subset
of those routes that have it enabled can add:
```ts
export const experimental_ppr = false
```
<details>
<summary>An aside on the choice of <code>experimental_ppr</code>
name</summary>
<blockquote>
<p>It is against common JS semantics to use snake-case, and preference
is given to camel-case instead. The choice to make this snake-case was
to re-enforce that this is an experimental feature, an ugly incremental
path, and ideally, developers should aim to remove all references of it
from their codebase.</p>
<p>Additionally, this mirrors what we've done for unstable API's like
`unstable_cache`.</p>
</blockquote>
</details>
To disable PPR for that segment and those descending segments. To use
this new option, the `experimental.ppr` configuration in
`next.config.js` must be set to `"incremental"`:
```js
// next.config.js
module.exports = {
experimental: {
ppr: "incremental",
},
}
```
If a segment does not export a `experimental_ppr` boolean, it is
inferred from it's parent. If no parent has it defined, it's default
value is `false` and therefore disabled.
Once all your segments have PPR enabled via this config, it would be
considered safe for teams to set their `experimental.ppr` value in the
`next.config.js` to `true`, enabling it for the entire app and for all
future routes.
### Aside
I also took the liberty to rename `isPPR` and `supportsPPR` to be the
clearer `isAppPPREnabled` and `isRoutePPREnabled`.
---------
Co-authored-by: Hendrik Liebau <mail@hendrik-liebau.de>
When `notFound()` is thrown from metadata, it's caught by a
`<MetadataOutlet />` rendered as a sibling to the page component. But we
currently only pass the custom not-found component to the
`<NotFoundBoundary />` for the `children` slot. This means that if a
parallel route throws a `notFound()` in `generateMetadata`, it'd be
caught by the root not found, which would be unexpected.
This mirrors the logic for determining whether or not a `notFound`
boundary should be provided. A side effect of this is that if you throw
a `notFound()` in `generateMetadata` for a segment that _only_ has
parallel routes, and no `children` slot, it won't be caught by the
boundary. But fixing this will require a larger refactor.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
Closes NEXT-3320
### Why?
`polyfill-nomodule.js` is a pre-built file containing polyfills for
older browsers (gated by the `<script>` tag `nomodule` attribute).
### How?
- The turbopack server needs to emit a raw OutputAsset for this file, so
that it is copied into the output chunks directory.
- That file needs to be passed into `polyfillFiles`, and preserved when
we're merging manifests inside of the development server.
### Test Plan
```
HEADLESS=true pnpm testonly-dev test/e2e/app-dir/app/index.test.ts -t 'should serve polyfills for browsers that do not support modules'
HEADLESS=true pnpm testonly-dev-turbo test/e2e/app-dir/app/index.test.ts -t 'should serve polyfills for browsers that do not support modules'
```
Build a project with `next dev --turbo` and inspect:
Verify that the polyfill file exists and resolves in the browser.
Closes PACK-2993
This should fix the following scenarios,
- Given a page defined like `app/foo/[...bar]/page.tsx`
- Given a page defined like `app/bar/[[...foo]]/page.tsx`
- Given a parallel route defined like `app/@slot/[...catchall]/page.tsx`
If you navigate to `/foo/bar` the `params` prop in the parallel route
would be
```js
params: {
catchall: [
'foo',
[ 'bar' ]
]
}
```
And if you navigate to `/bar/foo` the `params` prop in the parallel
route would be
```js
params: {
catchall: [
'bar',
'[ ...foo ]'
]
}
```
With the fix in place, the `params` prop in the parallel route will be,
```js
params: {
catchall: [
'foo',
'bar',
]
}
```
And
```js
params: {
catchall: [
'bar',
'foo',
]
}
```
Respectively
Fixes an issue with https://github.com/vercel/next.js/pull/65063 where
the catch-all param only contains dynamic segments and is missing
non-dynamic route segments.
This makes building breadcrumbs extremely hard as we're missing
information to properly render the correct breadcrumb components.
This fix makes parallel route catch-all params behave like the standard
catch-all params in non-parallel routes
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
### What
Follow up for #62873
Only apply credentials in metadata manifest tag for preview deployment
### Why
When the CORS header is "\*" and if you're including credentials in
request it will block by browser. For manifest's case, if it's fetching
from a publich CDN with responsing the CORS header "\*" and mismatching
with the current website domain it will get blocked. Previously we
introduced that change mostly for vercel deployment auth protection, now
we're going to check if it's preview deployment and also the same
origin, if yes then we'll include credentails for manifest request
Closes NEXT-3208
### What
Removing the Suspense boundary on top of `next/dynamic` by default, make
it as `React.lazy` component with preloading CSS feature.
### Why
Extra Suspense boundary is causing extra useless rendering. For SSR, it
shouldn't render `loading` by default
Related: #64060
Related: #64687
Closes
[NEXT-3074](https://linear.app/vercel/issue/NEXT-3074/app-router-content-flickering-with-reactcreatecontext-and-nextdynamic)
This is sort of a breaking change, since removing the Suspense boundary
on top of `next/dynamic` by default. If there's error happening in side
the dynamic component you need to wrap an extra Suspense boundary on top
of it
## What?
Ensures just importing `crypto` does not error, only when it is used it
shows an error in the edge runtime. This matches webpack behavior. The
`crypto` module was missing the list of unsupported packages in the
Next.js Turbopack integration.
Fixes#64464
Fixes PACK-2954
## TODO
While adding tests for this issue I found another bug that only happens
with webpack.
Specifically these 4 packages are accidentally being polyfilled even
when they're not set up to be polyfilled. i.e. there's no npm package
installed for polyfilling them through aliasing or such. Even in that
case `punycode`, `process`, `querystring`, and `string_decorder` get
polyfilled regardless, this causes the newly added test to fail.
Removing the polyfills would be potentially breaking so we'll want to
change it in Next.js 15 instead.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
Closes NEXT-3252
### What
* Fix `next/dynamic` with babel config and `src/` directory
* Separate the existing `next/dynamic` dev tests, make it easier to
cover more cases, add `.babelrc` + `src/` folder coverage case
### Why
* The new transform is using `src/` or root dir as the base directory
`next/dynamic` for generating relative module path as unique key for
`next/dynamic` modules. The babel one was always using the root dir
(`cwd`), which is incorrect. It should use the `src/` dir.
In the future we could make the different solution to generate the
unique id simpler, instead of using relative paths
Closes NEXT-3254
Closes NEXT-3251
Fixes#64741
### What
When a page throws a `notFound()` error in `generateMetadata`, and the
page contains parallel route(s), an unhandled runtime error would be
thrown rather than displaying the not found page.
### Why
We use the `<MetadataOutlet />` component to throw any errors caught
during metadata resolution once the metadata is rendered by React so
that it can be caught by an error boundary, so that it doesn't throw
during metadata resolution. A promise is tracked & resolved with an
error once the metadata tree is rendered. Once the promise resolves, the
outlet component will throw.
However, every `__PAGE__` segment that would be rendered as part of the
page the user is on will render this `<MetadataOutlet />` component. We
only need a single outlet per segment as only a single error needs to be
thrown & caught.
### How
This will only render a `MetadataOutlet` for the first parallel route
that is encountered at each segment depth, as we only need a single
handler to throw the error.
Fixes#65013
Closes NEXT-3222
When you do client navigation to a dynamic page with call like
`headers()`, it wil send RSC request for that page. We want to skip the
`_rsc` query in the logging as it's disruptive.
Closes NEXT-3077
Closes#64355
`server-utils` should not be imported into middleware as it contains
imports that won't work in the edge runtime. Those imports aren't
technically used, but it was causing a warning nonetheless.
This adds a regression test to confirm the warning is only present when
actually importing a Node.js module in userland.
Closes NEXT-3246
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
This extends #64520 to cover cases where client components originate
from node_modules (foreign code).
Test Plan: Extended the integration test to cover this
Closes#64412
Fixes PACK-3014
---------
Co-authored-by: OJ Kwon <1210596+kwonoj@users.noreply.github.com>
If a forwarded server action redirects, don't attempt to follow the
redirect as it can lead to errors. For example, if the forwarded request
followed a redirect to the same URL and had to forward the request
again, it'd hit a loop. The redirect will be handled by the
`X-Action-Redirect` which will be set when the forwarded action hits the
`createRedirectRenderResult` case.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
Closes NEXT-3243
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
### What?
When pages are rendered using partial prerendering (PPR), they can
easily trigger cases that attempt to interrupt static rendering. If a
user calls `fetch` from within a `unstable_cache` callback with `cache:
"no-store"`, we currently break out, as that fetch operation is called
within a cached callback.
### Why?
Without this change, using `unstable_cache` would have limited affect
when dealing with external code that explicitly sets `cache: "no-store"`
preventing it from utilizing the user-specified-cache.
### How?
This modifies the fetch patching so it doesn't bail static rendering due
to dynamic fetches within an `unstable_cache` callback.
Closes NEXT-3220
A common pattern for parallel routes is breadcrumbs. For example, if I
have a lot of dynamic pages, and I want to render a parallel route that
renders as a breadcrumb to enumerate those dynamic params, intuitively
I'd reach for something like `app/@slot/[...allTheThings]/page.tsx`.
Currently however, `[...allTheThings]` would only match params to a
corresponding `app/[allTheThings]/page.tsx`. This makes it difficult to
build the breadcrumbs use-case unless you re-create every single dynamic
page in the parallel route as well.
This adds handling to provide unmatched catch-all routes with all of the
params that are known. For example, if I was on
`/app/[artist]/[album]/[track]`, and I visited `/zack/greatest-hits/1`,
the parallel `@slot` params would receive: `{ allTheThings: ['zack',
'greatest-hits', '1'] }`
Fixes#62539
Closes NEXT-3230
## What?
Ensures paths that have spaces in them in `NODE_OPTIONS` are handled. An
example of that is VS Code's debugger which adds:
```
--require "/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/bootloader.js"
```
Currently the output is cut off and causes: `invalid value for
NODE_OPTIONS (unterminated string)`.
Related issue: https://github.com/vercel/next.js/issues/63740
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
Closes NEXT-3226
---------
Co-authored-by: Wyatt Johnson <accounts+github@wyattjoh.ca>
Co-authored-by: Ethan Arrowood <ethan@arrowood.dev>
### What
Cookies set/updated/removed in middleware won't be accessible during the
render in which they were set
### Why
Middleware will properly set a `set-cookie` header to inform the client
of the cookie change, but this means the `AsyncLocalStorage` context
containing the cookies value wouldn't be updated until the next time the
request headers were parsed. In other words, on the first request the
cookie would be sent but wouldn't be available in the `cookies()`
context. And then the following request would properly have the cookie
values.
### How
This uses a proxy on the `ResponseCookies` used in middleware to add a
middleware override header with the cookie value. When we instantiate
the cached cookies, we merge in whatever headers would have been set by
middleware, so that they're available in the same render that invoked
middleware.
### Test Plan
This changeset adds a test to confirm cookies set/deleted in middleware
are available in a single pass. Verified with a deployment
[here](https://vtest314-e2e-tests-ldx7olfl1-ztanner.vercel.app/rsc-cookies).
Fixes#49442
Closes NEXT-1126
### What
In case of socket raises errors and there aren't any listener to handle
it, node.js exits with non-0 exit code. So even test passes with all
assertion if socket raises an error while teardown (i.e socket destroyed
due to server process killed by test teardown) test will fail.
PR adjusts fixture setup by wiring empty error handler to write console
message to avoid those. If test assertion fails due to legit socket
error, we'll see error message. Otherwise we consider socket error is
not related with test.
- Closes PACK-3002
### What
See the PR's comment for the detail - TL:DR there is cases where test
case creates a connection to socket and it becomes a runaway, so
teardown logic hangs indefinitely. PR updates teardown to server to
force close any existing connections to prevents unexpected timeout.
This PR adds a new `experimental-test` command to Next.js CLI.
It has 3 main functions:
- auto installing missing playwright dependencies
- auto generating missing playwright config
- running tests via `playwright test`
I'm currently working on sharing a public RFC that will have more
information. I will link that here when its available.
Closes NEXT-3076 NEXT-3032
---------
Co-authored-by: samcx <sam@vercel.com>
### What
By testing locally, confirmed turbopack's build output is less optimized
and navigation takes long time so test assertion fails. Extending
timeout for now.
### What?
Add support to import attributes.
### Why?
The old import assertions syntax is deprecated and the proposal is
updated. See https://github.com/babel/babel/pull/15536
### How?
Add support to import attributes and keep old import assertions working
by using `@babel/plugin-syntax-import-attributes` with the
`deprecatedAssertSyntax` option.
Docs: https://babeljs.io/docs/babel-plugin-syntax-import-attributes
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
Co-authored-by: Steven <steven@ceriously.com>
### What
The "auto" prefetching behavior differs between dev/prod, resulting in
confusing DX when configuring `experimental.staleTimes = { static: 0,
dynamic: 0 }`.
### Why
Prefetching is intentionally disabled in dev, but we still will create
an "auto" prefetch on navigation. When configuring
`experimental.staleTimes` to have a `0` value in both static/dynamic
cases (a pattern that isn't a good idea, but should still have
consistent DX), it means that any auto prefetching that happens is
effectively discarded immediately, as we also would also not be able to
re-use the loading data.
In prod, we would have created a "temporary" prefetch for this case,
which is effectively not a prefetch at all and gets the full RSC data.
However in dev, we've special-cased these prefetches to be "auto", so
the client won't ever receive fresh data after the first time the cache
is seeded.
### How
This removes the special-handling for dev to instead be similar to other
prefetches that are created ad-hoc, and marks it as a "temporary"
prefetch kind. This has the added benefit of not triggering 2 separate
RSC calls in dev when only one is really needed.
### Test Plan
Client cache tests were previously disabled in dev because caching
behavior does intentionally differ between dev/prod. But we can at the
very least assert that the "auto" prefetching behavior is consistent
between the two environments, so that's what has been added to the tests
here.
This also adds a test for the `experimental.staleTimes = { static: 0,
dynamic: 0 }` case.
x-ref:
https://github.com/vercel/next.js/discussions/54075#discussioncomment-9202650
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
Closes NEXT-3209
This change allows disabling automatic `npm install`(or other supported
package managers).
Installing NextJS dependencies takes a long time and results in 0.5GB on
disk inside `node_modules`, it's not always what you want as sometimes
it's useful to delay dependency installation to a later time.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
## What?
Before: 25.71s
After: 11.05s (-57%)
## How?
Currently the system for isolation looks like this:
- Copy `packages` folder to an isolated directory
- Run `pnpm pack` for all folders in `packages`
- Collect the pack files, add them as `dependencies` in package.json of
the isolated application
- Run `pnpm install`
Because the `next-swc` (Turbopack + SWC, yes we still need to rename the
package) binary file is quite large in development (900MB+) it means we
have to copy, then zip (pnpm pack), then unzip (pnpm install) that
binary, which takes about 3+ seconds in each step.
The change in this PR is to skip the copy/zip/unzip completely by
providing the folder path for the binary directly to Next.js, as it's a
binary we don't need the special isolation for this, it's already
standalone so running it directly allows us to skip 14,6 seconds of work
that is required for each isolated test in development.
This will likely have little effect on CI times as we already do some
tricks like only running the packing at the start of the CI process.
Only thing that could be better and is probably worth doing is adopting
this change for the time it saves for unzipping, that's almost 4 seconds
per test still.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
Closes NEXT-3200
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
Add a validation for parallel routes with the same path.
This PR enables
`test/e2e/app-dir/conflicting-page-segments/conflicting-page-segments.test.ts`
### Why?
To match the behavior in the default mode.
### How?
Closes PACK-2912
We currently have logic spread in multiple places that normalize `nxtP`
parameters into their regular names, ie `nxtPfoo` -> `foo`. However we
don't apply this same logic to `nxtI`, which conceptually is another
parameter but for route interception. As a result, the interception
route would 404 when deployed because it'd be missing the interception
parameter.
This moves the normalization check into a util and updates the spots I
could find where we handle `nxtP` to also handle `nxtI`.
### Test Plan
Added a new test, and validated via these deploys:
**Working**:
[Link](https://vtest314-e2e-tests-m889gxi4p-vtest314-ijjk-testing.vercel.app/)
**Non-Working**:
[Link](https://vtest314-e2e-tests-8sa5t9uau-vtest314-ijjk-testing.vercel.app/)
Fixes#62207
Closes NEXT-3204
### What?
We tried to support proxy in next/font with turbopack, but wasn't able
to make upstream `reqwest` to support it with https protocol schemes.
Skipping for now for the RC and will revisit later.
### What
Apply the react aliases for app dir also to the files with
`pagesExtension`
### Why
In the page bundle of mdx page:
In RSC layer react is referencing to the insatlled react 18.2.0 's
`jsx-runtime` to create each JSX element. The react 18.2 JSX runtime
access `propTypes` of the component type and then it crashes 💥
In RSC layer it should use the built-in react canary's `jsx-runtime`.
The reason that it didn't use the built-in one is we're using customized
`pageExtension` `["mdx"]` for mdx, where we didn't apply all these rules
for the files with `pageExtension`, but only the js and ts files by
default.
For mdx specifically, we cannot only applied to
`(page|layout|route).[page extension]` cause every mdx file needs to
have proper resolution. Since this doesn't break transform, it's safe to
apply for all files with page extension.
Fixes#58888
Closes NEXT-3187
### What
* Remove the change added in #64467, but still kept tests.
* Add more tests for mixed imports (component and function) from shared
component with `optimizePackageImports`
### Why
The fix in #64467 was not correct, as mixing `export *` with `"use
client"` should error if Next.js detect it properly.
When there's mixed exports, that a shared function will become a client
reference if the target file inherits the client boundary.
The original issue #64467 fixed was actually related to tree-shaking,
which is fixed in #64681.
Closes NEXT-3197
### What
- closes#63896
PR implements parsing JSValue for the matcher config if given item is an
object. We had those types already declared in place but somehow parsing
ignores it.
### What
Closes PACK-2978, requires https://github.com/vercel/turbo/pull/8005.
PR extends existing mdxRs config from accepting object as well in
addition to current boolean flag, mainly to allow to specify what kind
of markdown types will be used between gfm and commonmark.
### What
Reported by @MaxLeiter, when you mixing named import and wildcard import
to a client component, and if you clone the module it will missed others
exports except the named ones. This lead to an issue that rendered React
element type is `undefined`.
### Why
We're using a tree-shaking strategy that collects the imported
identifiers from client components on server components side. But in our
code `connection.dependency.ids` can be undefined when you're using
`import *`. So for that case we include all the exports.
In the flight client entry plugin, if we found there's named imports
that collected later, and the module is already being marked as
namespace import `*`, we merge the ids into "*", so the whole module and
all exports are respected.
Now there're few possible cases for a client component import:
During webpack build, in the outout going connections, there're
connection with empty imported ids (`[]`), cannot unable to detect the
imported ids (`['*']`) and detected named imported ids (`['a', 'b',
..]`). First two represnt to include the whole module and all exports,
but we might collect the named imports could come later than the whole
module. So if we found the existing collection already has `['*']` then
we keep using that regardless the collected named imports. This can
avoid the collected named imports cover "exports all" case, where we
will expose less exports for that collection module lead to the
undefined component error.
Closes NEXT-3177
The function we use to generate a string with named parameters to pass
into `path-to-regexp` currently doesn't properly handle non-word
characters (namely, for the purposes of this bugfix, hyphens). As a
result, `pathToRegexp` will convert something like `/foo/:bar-baz` into
`/^\/foo(?:\/([^\/#\?]+?))-baz[\/#\?]?$/i`, effectively only treating
the `:foo` as part of the regex capture group and leaving a dangling
-baz.
This means using an interception route within a dynamic segment (such as
`/foo/[bar-baz]`) would not properly trigger the route interception
Fixes#64766
### What?
I submitted PR #64499 , it got merged, but it contains a mistake.
I'm terribly sorry about this!
By removing the traceparent from the cachekey, we mistakenly removed the
header from the original object.
Causing the actual request to be executed without the traceparent
header.
### Why?
Creating a cachekey should not alter the original object.
### How?
Flip the arguments for Object.assign
---------
Co-authored-by: Jeffrey <jeffrey@jeffreyzutt.nl>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
### What?
This ensures that the body limit option is enforced on all request
bodies sent to the Node.js runtime, not just the multipart field size
limits.
### Why?
The documentation states that this should limit the body size,
previously it only limited the field size.
### How?
This uses a `Transform` stream from Node.js. [Based on my
benchmarks](https://gist.github.com/wyattjoh/c470d98095da2f95f5920396aba2a206)
using the transform stream added next to no overhead, yet it did
simplify the implementation quite a bit. Assuming this is due to the
already performant stream support within Node.js.
Closes NEXT-3151
When a server action triggers a redirect, we're incorrectly applying a
refresh marker to the segment they were on, rather than the segment they
were being redirected to. As a result, when revalidation occurs (via
`revalidateX` or `router.refresh()`), the top-level segment would be
replaced with data for an incorrect segment.
For example, if triggering a redirect action from `/redirect` to `/`,
the router state tree would save a reference to `/redirect`. The next
time a refresh or revalidate happens, it'd refresh the segment data for
`/redirect` instead of `/`.
Fixes#64728
Closes NEXT-3156
## What?
In the past folks on the team have reported that anytime the SWC /
Turbopack binary changes they had to suddenly run `pnpm build-native` in
`packages/next-swc`, even though they didn't build from source before.
While investigating optimizing packing for tests I found that it's
copying the native binary into the original repository not the temporary
repository, which then keeps the file there, even after the tests
finish. This fixes the path to use the tmp repository instead.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
Closes NEXT-3157
When the router cache can't find a cache node for the requested segment,
it performs a request to the server to get the missing data. This
request to the server currently will always include the `next-url`
header, and on soft-navigations, the router will route the request to
the intercepted handler. This lazy fetch is treated as a soft navigation
by the server, and will incorrectly return data for the intercepted
route.
Similar to the handling in `router.refresh`, and the server action
reducer, we should not include the `next-url` header if there's no
interception route currently in the tree, as otherwise we'll be
erroneously triggering the intercepted route.
Fixes#64676
Closes NEXT-3146
Reverts vercel/next.js#64271
This appears to be causing problems rendering error boundaries on SPA
navigations and needs further investigation
Closes NEXT-3150
### Why
If you have a client entry that mixing `default` re-export and `*`
re-export, atm we cannot statically analyze all the exports from this
the boundary, unless we can apply barrel file optimization for every
import which could slow down speed.
```js
// index.js
'use client'
export * from './client'
export { default } from './client'
```
Before that happen we high recommend you don't mixing that and try to
add the client directive to the leaf level client module. We're not able
to determine what the identifiers are imported from the wildcard import
path. This would work if we resolved the actual file but currently we
can't.
### What
When we found the mixing client entry module like that, we treat it as a
CJS client module and include all the bundle in client like before what
we have the client components import optimization.
Ideally we could warn users don't apply the client directive to these
kinda of barrel file, and only apply them to where we needed.
Fixes#64518
Closes NEXT-3119
## Info
I did not create a GitHub issue, but this PR for fixing the issue. Hope
that's okay.
## The bug
We run a 'normal' custom server described here:
https://nextjs.org/docs/pages/building-your-application/configuring/custom-server
```ts
const next = require('next');
const dev = process.env.NODE_ENV !== 'production';
const port = 3000;
const app = next({ dev, port, quiet: !dev })
const handle = app.getRequestHandler()
// ...
```
The `quiet` settings is missed in some deeper Next.js internal api
calls. For that reason, the setting did not work at all. This works only
in production mode.
## Testing
I tried to implement a test in `/test/production/custom-server` but I
failed to get the `stderr` messages. When someone give me some guidance,
I will add a new test.
Here are some criteria:
- need: custom server with `quiet: true` setting
- need: a next.js page with thrown error. e.g. `export const
getServerSideProps = () => { throw new Error('failed') }`
- need: collect all `stderr` messages
I tested the fix in our project by editing the files in `node_modules`
-- it worked.
## Background
We upgrade our project from next `13.3.4` to `14.2.0` and saw this
regression. I can not tell in which version this bug was added. We run a
Next.js + 'custom server' + Docker setup. Because we have a lot of
traffic, we need to suppress the standard Next.js logging and using our
own logging.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
## What?
- Changes webpack output target to `es6` (required for `async function`
output)
- Adds tests for top level await in server components and client
components (App Router)
- Converted the async-modules tests to `test/e2e`
- Has one skipped test that @gnoff is going to look into. This shouldn't
block merging this PR 👍
Adds additional tests for top level `await`.
Since [Next.js
13.4.5](https://github.com/vercel/next.js/releases/tag/v13.4.5) webpack
has top level await support enabled by default.
Similarly Turbopack supports top level await by default as well.
TLDR: You can remove `topLevelAwait: true` from the webpack
configuration.
In writing these tests I found that client components are missing some
kind of handling for top level await (async modules) so I've raised that
to @gnoff who is going to have a look.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
Closes NEXT-3126
Fixes https://github.com/vercel/next.js/issues/43382
### Why
For app page rendering on edge, the `AsyncLocalStorage` (ALS) should be
bundled as same instance across layers. We're accessing the ALS in
`next/dynamic` modules during SSR for preloading CSS chunks. There's a
bug that we can't get the ALS store during SSR in edge, I digged into it
and found the root cause is:
We have both import paths:
`module (rsc layer) -> request ALS (shared layer)`
`module (ssr layer) -> request ALS (shared layer)`
We expect the ALS to be the same module since we're using the same layer
but found that they're treated as different modules due to applying
another loader transform on ssr layer. They're resulted in the same
`shared` layer, but with different resource queries. This PR excluded
that transform so now they're identical across layers.
### What
For webpack, we aligned the loaders applying to the async local storage,
so that they're resolved as the same module now.
For turbopack, we leverage module transition, sort of creating a new
`app-shared` layer for these modules, and apply the transition to all
async local storage instances therefore the instances of them are only
bundled once.
To make the turbopack chanegs work, we change how the async local
storage modules defined, separate the instance into a single file and
mark it as "next-shared" layer with import:
```
any module -> async local storage --- use transition, specify "next-shared" layer ---> async local storage instance
```
Closes NEXT-3085
### What
When rendering a parallel slot multiple times in a single layout, in
conjunction with using an error boundary, the following TypeError is
thrown:
> Cannot destructure property 'parallelRouterKey' of 'param' as it is
null
### Why
I'm not 100% sure of the reason, but I believe this is because of how
React attempts to dededupe (more specifically, "detriplficate") objects
that it sees getting passed across the RSC -> client component boundary
(and an error boundary is necessarily a client component). When React
sees the same object twice, it'll create a reference to that object and
then use that reference in future places where it sees the object. My
assumption is that there's a bug somewhere here, as the `LayoutRouter`
component for the subsequent duplicated parallel slots (after the first
one) have no props, hence the TypeError.
### How
Rather than passing the error component as a prop to `LayoutRouter`,
this puts it as part of the `CacheNodeSeedData` data structure. This is
more aligned with other properties anyway (such as `loading` and `rsc`
for each segment), and seems to work around this bug as the
`initialSeedData` prop is only passed from RSC->client once.
EDIT: Confirmed this is also fixed after syncing the latest React, due
to https://github.com/facebook/react/pull/28669Fixes#58485
Closes NEXT-2095
`initialCanonicalUrl` differs from the `canonicalUrl` that gets set on
the client, such as when there's a basePath set.
This hoists the `canonicalUrl` construction up so we can re-use it when
adding refetch markers to the tree.
This also renames `pathname` -> `path` since it also includes search
params. I added a test to confirm no extra erroneous fetches happened in
both cases.
Fixes#64584
Closes NEXT-3130
Since `AppRouterState` is promise-based (so we can `use` the values and
suspend in render), the state itself isn't stable between renders. Each
action corresponds with a new Promise object. When a link is hovered, a
prefetch action is dispatched, even if the prefetch never happens (for
example, if there's already a prefetch entry in the cache, and it
doesn't need to prefetch again). In other words, the prefetch action
will be dispatched but won't necessarily change the state.
This means that these no-op actions that don't actually change the state
values will trigger a re-render. Most of the context providers in
`AppRouter` are memoized with the exception of `LayoutRouter` context.
This PR memoizes those values so that consumers are only notified of
meaningful updates.
Fixes#63159
Closes NEXT-3127
### What
When middleware.js is present, the logging is duplicated. We should
filter out the 1st middleware request and only log the actual one going
through request handler / renderer
Closes NEXT-3125
When an action is marked as "discarded", we enqueue a refresh, since the
navigation event will be invoked immediately without waiting for the
action to finish. We refresh because it's possible that the discarded
action triggered some sort of mutation/revalidation, and we want the
router to still be able to respond to that new data.
However there's a bug in this logic -- it'll only enqueue the refresh
action if there were no other actions in the queue, ignoring the case
where something is still in the queue. This makes sure that the refresh
is handled after `runRemainingActions` finishes.
When adding a test for the server component case (which doesn't hit this
refresh branch), I noticed `LayoutRouter` caused React to suspend
indefinitely, because it got stuck in the `use(unresolvedThenable)`
case. We should only suspend indefinitely if we kicked off a the
`SERVER_PATCH` action, as otherwise it's possible nothing will ever
break out of that branch.
Fixes#64517
Closes NEXT-3124
## What
Determine if the client module is a CJS file and `default` export is
imported, then we include the whole module instead of using webpack
magic comments to only extract `default` export.
## Why
Unlike ESM, The `default` export of CJS module is not just `.default`
property, we need to include `__esModule` mark along with `default`
export to make it function properly with React client module proxy
Fixes#64518
Closes NEXT-3119
### What
This PR's goal is to improve the throughput performance of the Next.js
server when handling Pages Router routes.
Note that the results from this are very synthetic and do not represent
the real-life performance of an application. If we only wanted to handle
hello worlds, we could probably make this even faster but on production,
a slow fetch call to your DB is probably what's slowing you down.
I'll look into App Router next.
### Why?
I guess I got nerd-sniped into it 😃
### How?
A few optimizations:
- I looked deeply at the pipeline for rendering a Pages Router page. I
noticed a lot of intermediary streams being created here and there to
eventually be concatenated to a simple string. I think this is probably
left over code from when we wanted to support streaming there and so
there's some code that was shared with the App Router, which we
absolutely don't need I think. I refactored it to be slightly simpler
with just a few string concats here and there.
- misc: I removed some redundant Promises being created here and there
and added a small inline optimisation to eliminate `if (renderOpts.dev)`
code in production.
### Nummies
Test setup: hello world pages router app, next start + autocannon
- requests handled in 10s: 18k -> 33K, **~80% improvement**
- avg latency: 4.89ms -> 2.8ms, **~42% improvement**
- avg req/res: 1846.5 -> 2983.5, **~61% improvement**
Before
<img width="742" alt="image"
src="https://github.com/vercel/next.js/assets/11064311/658e7ade-eba7-4604-a7c9-619bd51a5ec8">
vs
after
<img width="880" alt="image"
src="https://github.com/vercel/next.js/assets/11064311/2f46cf69-b788-4db2-bf90-6f65dc7abd82">
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
Closes NEXT-3103
### Summary
Fixes#52935
`next/script` has a `Script` component that supports an `async` prop.
However, when scripts are loaded with the `async` prop set to false, the
script is loaded as if async was set to true. This may cause scripts to
execute out of order. Repro:
https://github.com/domdomegg/next-async-script-reproduction
I think this is occurring because Next uses setAttribute to set the
async and defer attributes. However, this is not a valid way to set
these properties on a script. This is because . Demo:
https://jsfiddle.net/6ktpfae1/
This PR fixes this behaviour by using removeAttribute after calling
setAttribute (rather than using setAttribute "false"). This appears to
result in correct behaviour.
Given it appears this workaround was already applied in `next/head`,
I've harmonised the code between these two.
### Next steps
I think this PR is ready for review. I acknowledge there are no test
changes, but there are no existing tests for `next/script` at all and
creating them I think would be disproportionally difficult given issues
in #52943.
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: Sam Ko <sam@vercel.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Resolves#64412
This adds a client transition to the app route `ModuleAssetContext` and
the corresponding transforms so that client components can be safely
imported and referenced (as their proxies) in app routes.
Test Plan: Added an integration test
Closes PACK-2964
cc @shuding
CI run failed after #63053 on turbo production, which had not yet been
targeted for turbo.
x-ref: #63103
---------
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Co-authored-by: Leah <8845940+ForsakenHarmony@users.noreply.github.com>
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
### What?
The string value of `Metadata.openGraph.emails` throws error:
```tsx
export const metadata = {
openGraph: {
type: 'article',
emails: 'author@vercel.com',
},
};
```
Error:
```sh
r.map is not a function
```
The type is:
```tsx
type OpenGraphMetadata = {
// ...
emails?: string | Array<string>
}
```
### Why?
Basic values such as `emails` and `phoneNumbers` were not included when
`ogType` was set while resolving the values.
### How?
Include basic values when resolving the metadata.
Fixes#63415
This ensures we properly skip calling a fetch during build-time that has
`cache: 'no-store'` as it should only be called during runtime instead.
Fixes: https://github.com/vercel/next.js/issues/64462
Closes NEXT-3114
## Why?
For multi-root layouts (route groups on the root with their root
layouts, no layout file on the root), it is not possible to use global
`not-found` since the `layout` is missing on the root.
```sh
.
└── app/
├── (main)/
│ └── layout.js
├── (sub)/
│ └── layout.js
└── not-found.js --> ERR: missing layout
```
Current Behavior:
```sh
not-found.js doesn't have a root layout. To fix this error, make sure every page has a root layout.
```
## What?
Let multi-root layouts also benefit from the global `not-found`.
## How?
Wrap root `not-found` with default layout if root layout does not exist.
Although this solution is not `multi-root` specific, it won't produce
critical issues since a root `layout` is required for other cases.
Fixes#55191#54980#59180
### 🤔 What's in there?
We've deprecated config's `analyticsId` in 14.1.1 [almost 3 months
ago](https://github.com/vercel/next.js/releases/tag/v14.1.1-canary.2).
Users can opt in fot `@vercel/speed-insights`, or use
`useReportWebVitals` to report to any provider they'd like.
This PR:
- removes `analyticsId` key from configuration
- stops setting `__NEXT_PUBLIC_ANALYTICS_ID` env variable when the key
was present
- stops injecting `performance-relayer` file, when the variable is set
- cleans up related test code.
### What
Inherit the client boudaries from the found matched target in load
barrel
### Why
The root cause with the barrel transform, we missed the client boundary
directive during the transform.
Since the new version of mui's case looks like this:
Import path
page.js (server module) -> `<module>/index.js` (shared module) ->
`<module/subpath>/index.js` (client module) ->
`<module/subpath/sub-module.js> (client module)
After our transform, we lost the `"use client"` which causes the
mismatch of the transform:
In `rsc` layer: the file pointing to the sub module entry
(`<module/subpath>/index.js`), but without the client boundary.
Fixes#64369
Closes NEXT-3101
Since the router processes events sequentially, we special case
`ACTION_NAVIGATE` events to "discard" a pending server action so that it
can process the navigation with higher priority. We should apply this
same logic to `ACTION_RESTORE` events (e.g. `router.back()`) for the
same reason.
Fixes#64432
Closes NEXT-3098
`fetchCache` is a more fine-grained segment level cache-control
configuration that most people shouldn't have to use. Current semantics
of `dynamic = "force-dynamic"` will still treat the fetch as cacheable
unless explicitly overriding it in the fetch, or setting a segment level
`fetchCache`.
The `dynamic` cache configuration should be seen as a "top-level"
configuration, while more fine-grained controls should inherit logical
defaults from the top-level. Otherwise this forces people to opt-into
the `fetchCache` configuration, or manually override each `fetch` call,
which isn't what you'd expect when forcing a segment to be dynamic.
This will default to not attempting to cache the fetch when
`force-dynamic` is used. As a result, I had to update one of the
`app-static` tests to use `revalidate: 0` rather than `force-dynamic`,
as the revalidate behavior is slightly different in that it won't modify
the revalidation time on a fetch if it's non-zero.
Closes NEXT-2067
The fix is not correct, we already have request ALS wrapping the request
in app-render, shouldn't get another one for edge adapter. This is
actually a bundler bug
Reverts vercel/next.js#64382
Closes NEXT-3097
### What
Wrap async local storage for all edge runtime routes in adapter
Basically fixed the case reported in [this
tweet](https://x.com/keegandonley/status/1778538456458854880)
### Why
We're relying on the ALS for dynamic css preloading but we didn't wrap
the ALS for request handlers for edge. So if you have CSS imports in
`next/dynamic` in edge runtime it would break.
Closes NEXT-3085
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
### What?
This adds a missing test case for a page which accesses dynamic API's
within `generateMetadata`. It also adds a test case to verify that any
of the URL's being tested can succeed based on the components link
components (it relies on finding a link to click in the browser).
Closes NEXT-3004
## Why
Currently, Server Action handlers are just normal routes and they
accepting POST requests. The only way to differentiate a normal request
(page access, API route, etc.) from a Server Action request is to check
that if it's a POST and has a Server Action ID set via headers or body
(e.g. `multipart/form-data`).
Usually, for existing page and API routes the correct handlers (page
renderer, API route handler) will take precedence over Server Action's.
But if the route doesn't exist (e.g. 404) it will still go through
Server Action's handler and result in an error. And we're eagerly
logging out that error because it might be an application failure, like
passing a wrong Action ID.
## How
In this PR we are making sure that the error is only logged if the
Action ID isn't `null`. This means that it's an intentional Server
Action request with a wrong ID. If the ID is `null`, we just handle it
like 404 and log nothing.
Fixes#64214.
Closes NEXT-3071
### What
Bump the edge runtime manifest version and add `environments` property
to each route for inlining values for deployment build.
### Why
In edge runtime, extract the preview props into edge functions manifest
that holding the non-deterministic inline values, then the output build
will be more deterministic that helps deployment speed
x-ref: https://github.com/vercel/vercel/pull/11390
x-ref: https://github.com/vercel/vercel/pull/11395
Closes NEXT-3012
Closes NEXT-1912
### What?
This adds a script that first gets a list of changed files compared to
our base branch (`canary`) in PRs and identifies related test files by
looking them up from a `related-tests-manifest.json`, then runs them.
### Why?
We would like to be able to run related E2E tests when certain files
change, so we can test deployment stability.
NOTE: We still want to run all E2E tests on PRs, but this script can be
used to also test deployments for hot paths. Since these tests can take
up to [3-4
hours](https://github.com/vercel/next.js/actions/workflows/test_e2e_deploy.yml),
we aim to run a subset of these tests first.
Closes NEXT-2947
Building on #58293, this expands escaping of url-unsafe characters in
paths to “required” scripts and styles in the app renderer.
This also refactors the test introduced in #58293 and expands it to
include stylesheet references as well as checking resources in the head,
which include special characters like turbopack references like
`[turbopack]`.
Test Plan: `TURBOPACK=1 pnpm test-dev
test/e2e/app-dir/resource-url-encoding`
Closes PACK-2911
