Adds process.env.__NEXT_PPR as static flag that it gets inlined by
DefinePlugin during build.
This matches what we do for other experiments, but I do wonder, why do
we bother with process.env at all instead of a global __NEXT_PPR symbol?
I'll leave that for later discussion.
Closes NEXT-1792
Similar in spirit to #58938.
The app router reducer state used to be managed by useReducer, so it was
written to be resilient to rebasing — the same action may be processed
multiple times. Now that we've lifted the reducer outside of React
(#56497), each action runs only a single time. So we can simplify some
of the logic.
The purpose of the `mutable` field was so that if an action is processed
multiple times, state could be reused between each run; for example, to
prevent redundant network fetches. Now that this scenario can no longer
happen, we can remove it.
I had to update some of the unit tests in navigate-reducer because they
were written with the assumption that the reducer was called multiple
times. As far as I can tell, most of this behavior is covered by e2e
tests anyway, so I don't think it's too risky.
Closes NEXT-1782
### What?
A follow up for #58267 and #58394.
We no longer need the git branch for history it's stored in datadog now
and we also decided that we no longer need slack reporting.
Closes PACK-2039
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
## What?
Skips more tests that are running `next build` which is not supported by
Turbopack yet.
## How?
Used an approach where all `next build` tests would fail if
`TURBOPACK=1` is set, which is how the tests run. This highlighted the
cases `next build` was still running.
<!-- 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-1791
This resolves an issue introduced in #52361 where `shouldOmit` is
overwritten based on if it is a directory or not without considering
include conditions.
In an environment where the the application being built is orchestrated
and managed by bazel, all files are symbolic links and thus without this
the file includes predicate checks aren't considered - and the build
fails under certain conditions.
<!-- 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: Shu Ding <g@shud.in>
This ensures we use the correct `srcPathname` in minimal mode so that we
can normalize the URL and generate the correct `ssgCacheKey` which is
used for request caching/de-duping.
We aren't able to add a reliable test case for this as it is a race
condition within a second of a previous request although this was
verified against a stress test repro here
https://overlapping-segments-h1455lwvk-vtest314-ijjk-testing.vercel.app/repro/tutorials/demo
This behavior seems to have regressed in
https://github.com/vercel/next.js/pull/45716
Closes NEXT-1777
### What?
When using a server action on an intercepted route, when submitting that
action, you'd expect it to correspond with the page you're currently on.
However if you have route interception set up, and you load the page
rather than the intercepted page, submitting the action would `POST` to
the intercepted page. This would result in a 404 error because the
action ID you're attempting to submit wouldn't be found on the requested
page.
### Why?
Interception routes rely on the `Next-Url` request header to determine
if an interception should occur via a rewrite. However, server actions
are submitted with this header as well, so the rewrite will be applied
to the `POST` request corresponding with a non-existent action, or an
action on the intercepted page.
### How?
When loading a page that has an intercepted route, `nextUrl` should be
consistent with URL derived from the flight router state tree. But when
an interception occurs via navigation, `nextUrl` will now deviate. I'm
using this to determine whether or not `Next-Url` should be forwarded
along in the `POST` request.
Closes NEXT-1436
Fixes#52591Fixes#49934
### What?
When using rewrites, in the scenario where a user visits an intercepted
route, reloads the page, goes back, and then revisits the same route, we
serve the page rather than the intercepted route.
### Why?
#59094 fixed the case where `ACTION_RESTORE` was not restoring `nextUrl`
properly. However there's a separate issue where when the `SERVER_PATCH`
action comes in, `handleMutable` attempts to compute `nextUrl` by
comparing the patched tree with the current tree. In the case of the
popstate event, both trees are the same, so the logic is currently
configured to fallback to `canonicalUrl`, which is not the correct URL
to use in the case of rewrites.
### How?
If the computed changed path is null, we should only fallback to using
`canonicalUrl` if we don't have a valid `nextUrl` that we can use.
Closes NEXT-1747
Fixes#56072
## What?
While investigating a Turbopack bug we noticed that middleware would be
skipped in development if there was an error during compilation that
caused `ensurePage` to throw. This updates the logic to not catch that
throw and instead make it bubble up 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 auto-generated PR updates the integration test manifest used when
testing Turbopack.
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
**Note**: this is a 1-to-1 copy of #48969 by @danieltott with all the
merge conflicts fixed.
## Checklist
* Fixes https://github.com/vercel/next.js/issues/48966
* Tests added to
`test/production/app-dir/subresource-integrity/subresource-integrity.test.ts`
## Description
Currently `renderToHTMLOrFlight` in app-render pulls out a nonce value
from a `content-security-policy` header for use in generating script
tags:
e7c9d3c051/packages/next/src/server/app-render/app-render.tsx (L1204)
That misses the ability to use a [content-security-policy-report-only
header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only).
Many times this is a required step to enabling a CSP - by shipping a CSP
with report-only and collecting reports before actually blocking
resources.
## Changes
* Added ability to check `content-security-policy-report-only` header in
`renderToHTMLOrFlight()`
* Added test to verify `nonce` is correctly applied when
`content-security-policy-report-only` header exists
Co-authored-by: Dan Ott <dan@dtott.com>
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
If a manual signal handler is registered, SIGINT and SIGTERM should not
be handled by Next.js. This was already the case in the standalone
server.js but was missing here, rendering the env flag useless.
With this fix, the example given in
https://nextjs.org/docs/pages/building-your-application/deploying#manual-graceful-shutdowns
is working (again).
Fixes#56810.
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
When using `experimental.typedRoutes` in conjunction with
`experimental.webpackBuildWorker`, type errors would be erroneously
thrown during build.
This is because the build workers are parallelized between multiple
runtimes (edge, server, client), but the `typedRoutes` is unique to each
`webpackBuild`. The state needs to shared between the different compile
steps for each instance of the types plugin.
This leverages plugin state to keep share the `typedRoutes` state
amongst the different workers.
Closes NEXT-1734
Fixes#58369
