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 #
-->
We already have workers available when determining if a page is static,
and we expose those workers to the page export handler. We should re-use
those workers instead of creating new ones.
In practice this seems like dead code, since `setupWorkers` returns the
existing workers if a pages worker exists, and we always create a pages
worker.
<!-- 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 bumps the supported `msw` version when using the `playwright` test
mode. There's no need for mocking requests and responses anymore since
[they adopted](https://github.com/mswjs/msw/pull/1436) the global fetch
API in `msw`.
### Why?
Users can extend `test` from `playwright` manually and create the `msw`
fixtures, but it's better if it works out of the box with newer versions
of `msw`.
Fixes#63338.
Co-authored-by: Sam Ko <sam@vercel.com>
Effectively a revert of https://github.com/vercel/next.js/pull/66006,
but:
- Keeps the cleanup changes from that PR.
- With https://github.com/vercel/nextpack/pull/106 removing the explicit
`--features plugin` flag, we will match behavior between cargo's
defaults and the nextpack development scripts (which we want to do for
maximizing cache reuse).
The tradeoff here is faster cold builds, at the cost of waiting longer
when you want to test with plugins.
Feedback from @kdy1 was:
> I think it's a good idea to disable plugin by default for nextpack. We
don't use it for most of daily development, but it's very large and slow
to compile
Tested by running both:
```
pnpm build-native
pnpm build-native-no-plugin
```
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
Add copy stack trace button to copy the original stacktrace in error
overlay.
It will be a dimmed red button with disallowed cursor when it's found
not able to copy.
#### Video
https://github.com/vercel/next.js/assets/4800338/c44e0bf8-f340-41ba-8ee8-4b94fdc298e1
### Why
Makes error reporting easier, users can do one-click to copy the
original text
### What
Removing the `/[...catchall]/<metadata image convention>.js` case from
docs
### Why
Since og image and icon routes are using catch-all routes to handle the
both single or multiple routes. For instance:
`app/opengraph-image.js` can possibly generate two cases:
- single route: `/opengraph-image`
- multi routes with `generateImageMetadata()`: `/opengraph-image/[id]`
We're not able to detect if there's `generateImageMetadata` defined in
the file before mapping the routes, and decided to create the different
routes to either `/opengraph-image` or `/opengraph-image/[id]`. That's
why we're using a catch-all routes to handle them rn.
Related #48106
Related #57349
### 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>
In preparation for the following request adapter work, this removes a
helper function for checking if a request is an RSC one, instead
preferring to use the metadata directly.
This helps readability because we know where it's coming from, and it
keeps the implementation simple.
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>
### What
* Error on case that readable stream controller tries to close but
stream is either errored or unfinished
* Delay the DOMContentLoaded event to avoid "Connection Closed" error
### Why
Regarding to the new error about readbale stream controller, the new
error we added here is for identifying the connection is closing before
the last bit has been received that's an error case not intentional
close. It's not a proper state for close more for erroring.
As for adding the queuing for the task of dom content loaded callback,
after investigation, I found that if the DOMLoaded execute earlier the
readable stream controller cuold close earlier on client, which lead to
the "Connection Closed." error. Hence we added a `queueMicroTask` here
to delay it after hydrate call.
x-ref: [slack
thread](https://vercel.slack.com/archives/C01A2M9R8RZ/p1715188343813489)
### What
It's not helpful to see the network issue of fetching error on reading
nextjs version in dev overlay
### Why
Error case:
<img width="400"
src="https://github.com/vercel/next.js/assets/4800338/a7852d9b-1f98-4098-8498-a3b832efdbb0">
This should just be ignored, it's fine that the fetching is failed.
There're so many fetch errors code, it's easy to try-catch on fetch
instead of enumerate all the codes
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).
Updates `with-react-hook-form` example by bumping react-hook-form and
other dependencies to their latest versions, along with a minor cleanup
of the UI.
---------
Co-authored-by: Sam Ko <sam@vercel.com>
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.
