Transient/recoverable errors can cause page(s) to fail. When building an
app with a lot of static pages, a single page failing to build can be
frustrating, especially if it it'll pass on a retry. This adds an
experimental `staticPageGenerationTimeout` property that can be used to
configure how many times Next.js attempts to build a particular page
before giving up.
I recommend reviewing this PR [without
whitespace](https://github.com/vercel/next.js/pull/66393/files?w=1)
<!-- 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 modifies the patched fetch implementation to better handle when
called within an `unstable_cache` callback. In these callbacks, it
should not throw an error related to dynamic access.
This replaces the verbose `trackDynamicFetch` instead with
`markCurrentScopeAsDynamic` which already has support for checking if
inside an unstable cache context. It also has been adjusted to be a
no-op when `export const dynamic = "force-static"`, further simplifying
the code within the patch fetch implementation.
### What
Use `next-flight-loader` to transform the client components into client
reference in middleware and instrumentation.
Add related required webpack aliases, such as alias for
`react-server-dom-webpack`
### Why
issue reported in
https://github.com/vercel/next.js/pull/65424#issuecomment-2128902585
### What?
Because `createMultiHtmlMatcher` does not use `await` keyword internally
and is not an async function, all `await` in front of the match function
returned from `createMultiHtmlMatcher` was removed in
`test/e2e/app-dir/metadata/metadata.test.ts`.
The JSDoc for `createMultiHtmlMatcher` was also modified.
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
This allows us to set breakpoints and debug e2e tests without
encountering a timeout after 60 seconds. For example, using:
```
NEXT_E2E_TEST_TIMEOUT=1000000 NODE_OPTIONS=--inspect-brk pnpm test-dev test/e2e/app-dir/metadata/metadata.test.ts
```
Notably, this change also affects the turbopack dev tests in the CI,
where `NEXT_E2E_TEST_TIMEOUT` is currently set to 240 seconds. Since the
same env variable is also used for `jest.setTimeout()`, a test timeout
will now most likely occur due to jest timing out, and not a specific
playwright check (i.e. `waitForElementByCss` or `waitForCondition`)
timing out. This sounds acceptable to me.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Using the hostname `::` enables dual-stack support. This prevents
`ECONNREFUSED` errors when running tests locally, and `localhost` being
resolved to `::1` (IPv6) instead of `127.0.0.1` (IPv4).
During integration testing, previously, calls to `next build` could rely
on the project (the Next.js project) level ESLint configuration. In
order to correct this, a new `lint` option was added to `nextBuild` that
can be passed to enabled linting. If this is `false` or `undefined`, a
`--no-lint` argument will be passed to `next build` to prevent it from
running.
Old logic from the pages router was previously being hit during
development. This was more apparent when PPR was enabled as it was
mixing dynamic + static rendering in development which propagated to
errors. This change ensures that requests that are made with `RSC: 1`
are not marked as `/_next/data` URL's, and don't use the same logic
paths.
Previously it was a bit confusing because we used the variable
`isDataReq` in a few places that made it hard to tell what it was
referring to. In this case, the `isDataReq` is actually only used by the
pages router. This renames the `isDataReq` to `isNextDataRequest` to
make it clearer, as well as refactors to ensure that it's not used in
the paths for app routes.
Also to better represent the rendering modes the `supportsDynamicHTML`
variable was renamed to `supportsDynamicResponse`.
Fixes#66241
Revert the revert in #66049
It was erroring in pages api with importing `react-dom/server` as this
is disallowed in app but shouldn't be in pages. It's caused by we're
validating middleware layer as server components but edge pages api is
still bundled in the same layer, where we shouldn't apply the check.
* Separate the api in api layers, and while handling middleware
warnings, checking api layer as well
* No need to check layers while handling externals in edge compiler
* Found a bug that we shouldn't check if `config.transpilePackages` is
defined then we enable `externalDir`, removed that condition. It fails
the telemetry tests case build with code change from this PR.
Add more tests for pages dir and middleware
| | `react` condition | `react-dom/server` condition |
| ---- | ---- | ---- |
| middleware (edge) | react-server | not allowed, failed with dev/build
checks |
| pages/api edge | default condition | default condition |
| pages/api node | default condition | default condition |
This reverts commit
637033c410.
What wasn't clear originally is that we require that required packages
have their `package.json` resolvable. So either they don't have an
`exports` field, or their `package.json` is listed in the `exports`
field. The React beta types didn't have `package.json` entry in
`exports` so we accidentally thought they weren't installed.
I published [`19.0.0-beta.2` that has `package.json` in
`exports`](13879ee571 (diff-81cc573aa0c2bd0e13f9463499747741704aabccd7474f544db710befd7bcfc4R44))
so we can restore the old behavior. It's still questionable IMO to do
all that I/O work just for a nicer error message that may contain
false-positive but that's for another time.
This PR changes the `getWaitUntil` logic to always check if the platform
provided a request context with a `waitUntil` implementation (via [the
`@next/request-context`
symbol](05e6b82576/packages/next/src/server/after/wait-until-builtin.ts (L12)))
, regardless of minimalMode or runtime.
Previously, we wouldn't check the context at all unless `minimalMode`
was set, and defaulted `waitUntil` to a noop otherwise. This would make
integration more difficult for providers who don't use `minimalMode`,
because they'd have no way to inject their `waitUntil` implementation.
Ensures that app routes (like the `favicon.ico` added in the test case
in this PR which is represented as an app route) do not have a prefetch
RSC also attached.
## Background
Previously we introduced automatic caching for `fetch` based on certain
heuristics that were a bit tricky to grasp all scenarios. The scenarios
we would automatically cache were no dynamic data access before the
fetch call e.g. `headers()` or `cookies()`, the fetch call is inside of
a dynamic page e.g. `POST` method or `export const revalidate = 0` page
and the fetch is a non-`GET` request or has `Authorization` or `Cookie`
headers, or the fetch had `cache: 'no-store' | 'no-cache'` or
`revalidate: 0`.
## New Behavior
By default fetches will no longer automatically be cached. Instead they
need to be opted-in to caching via `export const fetchCache =
'default-cache' | 'force-cache',` `next: { revalidate: false or value >
0 }` or `cache: 'force-cache' | 'default-cache'`.
When the fetch call is automatically skipping the cache it won't impact
the page level ISR cacheability although if a fetch call manually
specifies `cache: 'no-store'` or `revalidate: 0` it will still bail from
the page being statically generated as it was before.
To achieve the previous behavior of automatic fetch caching all that
needs to be added is `export const fetchCache = 'default-cache'` in the
root layout(s) of your project.
Follow-up to https://github.com/vercel/next.js/pull/65825 this ensures
we don't skip the static optimization specifically for metadata routes
as this most often should be static as they aren't dynamic content and
are requested very frequently.
This configures the default client router cache `staleTime.dynamic`
value to be `0`.
This means that:
- Navigating between pages will always fire off a network request to get
RSC data for the page segment, rather than restoring from router cache
- Loading states will remain cached for 5 minutes (or whatever
`config.experimental.staleTimes.static` is set to)
- Shared layout data will continue to remain cached due to [partial
rendering](https://nextjs.org/docs/app/building-your-application/routing/linking-and-navigating#4-partial-rendering)
- Back/forward behavior will still restore from cache to ensure the
browser can restore scroll position.
It's possible to opt-out of this, and into the previous behavior, by
setting the
[`staleTimes`](https://nextjs.org/docs/app/api-reference/next-config-js/staleTimes)
config in `next.config.js`:
```js
/** @type {import('next').NextConfig} */
const nextConfig = {
experimental: {
staleTimes: {
dynamic: 30
},
},
}
module.exports = nextConfig
```
<!-- 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 reverts the below changes to avoid a breaking change in pages with
importing `react-dom/server` as this is disallowed in `app` but
shouldn't be in `pages`.
Revert "Bundle the installed react for middleware (#65811)"
Revert "Error in build for middleware when import client-only (#65792)"
This reverts commit fdd8f0c65f.
This reverts commit 082072ca95.
x-ref: [slack
thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1716305493514869)
Noticed while testing turbopack version of tests that we weren't loading
the correct swc binary since this path wasn't absolute and was just the
relative path in `node_modules`.
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
Since, https://github.com/vercel/next.js/pull/65830, I've been seeing
weird flakes from
`test/e2e/app-dir/app-invalid-revalidate/app-invalid-revalidate.test.ts`.
```
TIMED OUT: /Invalid revalidate value "1" on "\/", must be a non-negative number or "false"/
```
The build output looks like this:
```
▲ Next.js 14.3.0-canary.73
Creating an optimized production build ...
[snip]
Error: Invalid revalidate value "1" on "/_not-found", must be a non-negative number or "false"
[snip]
Generating static pages (2/4)
> Build error occurred
Error: Export encountered an error on /_not-found, exiting due to prerenderEarlyExit: true being set
```
Note that there's no `Invalid revalidate value "1"` message for `/`, so
the test will fail.
This looks like a race condition: the invalid `revalidate` value is set
in a layout, so if `_not-found` happens to be prerendered before `/`,
it'll abort the whole prerender (because of `prerenderEarlyExit: true`).
so if the timing is right, the test -- which is looking for build errors
for `/` -- will never see them and time out.
There might be more of these, but unfortunately they're basically race
conditions, so I think we'll have to squash them as they come up.
CC @ijjk
## 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.
