## What?
- Add support for `experimental.externalDir` -- Was already supported,
just makes Turbopack not fail on that config option
- Skipped `with-babel` test because it tests Babel
- Skipped `swc-warnings` test because it tests Babel
- Skipped `config-resolve-alias` as it tests webpack config
- Skipped `undefined-webpack-config` as it tests webpack config
<!-- 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-1817
### What?
Visiting an edge catch-all route incorrectly truncates multiple
parameters
### Why?
The params are currently coerced into a `ParsedURLQuery`-like format by
calling `Object.fromEntries` on `searchParams`, but this doesn't
consider multiple param values assigned to the same key
### How?
Rather than use `fromEntries`, this uses an existing util to get the
path into `ParsedURLQuery` format.
Closes NEXT-1814
Fixes#59333
### What?
When running a
[multi-zone](https://github.com/vercel/next.js/tree/canary/examples/with-zones)
app in dev, app pages would infinitely reload
### Why?
The HMR upgrade request would fail and get caught into a retry loop. In
the multi-zone case, they fail because the upgrade request would be sent
again for a request that had already been upgraded. This resulted in a
"server.handleUpgrade() was called more than once with the same socket"
error, causing the upgrade request to fail.
Every time a retry occurred, the page would trigger a full refresh since
certain HMR errors cause the browser to reload.
### How?
This ensures the upgrade handler only responds to requests that match
the configured basePath.
Closes NEXT-1797
Fixes#59161Fixes#56615Fixes#54454
This makes some critical modifications to the app render pipeline when
PPR has been enabled for pages with segments defining:
```js
export const dynamic = "force-dynamic"
```
Importantly, it no longer modifies the revalidation time to zero for
those pages, and now falls back to the provided default revalidation
time. When static render occurs, if the page being rendered has a
segment config defining `dynamic === "force-dynamic"`, then it will
postpone at the root of the component tree. This ensures that no render
code is executed for the page, as the entirety of the tree will have
postponed. This fixes the bug where the flight prefetch wasn't generated
correctly as well.
### What?
Using an interception marker next to a dynamic segment does not behave
properly when deployed to Vercel
### Why?
The named route regex that gets created is not accounting for the
interception marker, which is causing the non-intercepted route to match
the intercepted serverless function.
### How?
This factors in the interception marker when building the named route
regex so that the non-intercepted route regex properly matches when
loading the non-intercepted page.
Deployment verified here: https://test-intercept-mu.vercel.app/
Closes NEXT-1786
Fixes#54650
Fixes#57624. The recent issue was an unexpected side effect caused by
305bb01506,
which only affects specific packages like `@mui/material`.
The problem was that the entry file of `@mui/material` has `"use
client"` at top, which affects the compilation result to output
reference info only (when on the RSC layer), instead of keeping the
original export statements. And the fix here is to ignore all layer info
and React specific transforms here, as barrel optimization isn't related
to all these framework features at all. To keep all directives
unchanged, the SWC transform needs to parse and pass that info to the
Webpack loader.
This PR adds a test to ensure that `@mui/material` is working as
expected (less than 1500 modules compiled). Without this feature it'll
be ~2400 modules.
Closes NEXT-1793, closes NEXT-1762.
## 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>
### 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
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>
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
This:
- Sends an hmr sync event so that errors that occur after the initial
hmr connection are sent to the client
- Aligns on `path/to/file.js:line:column` format across error overlay
implementations in the cli and on the web
- Adapts "Module not found" errors from Turbopack to include
Next.js-relevant formatting and documentation links to align with
webpack
Test Plan: Passes 3 tests that were previously failing
Closes PACK-1974
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: Leah <github.leah@hrmny.sh>
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What?
When using interception routes & rewrites, on first interception the
router will properly handle the request. But when using the back button
and attempting another interception, it won't work
### Why?
Intercepting routes rely on the accuracy of `nextUrl` -- but when
`ACTION_RESTORE` is dispatched (in the `popstate` event), `nextUrl` is
restored from `url.pathname` rather than the flight router state.
### How?
This uses the `extractPathFromFlightRouterState` util which will
properly handle setting `nextUrl`. This util is also used when creating
the initial router state.
Closes NEXT-1747
Fixes#56072
### What?
When handling a server action, in the non-progressive enhanced case,
React will attempt to parse the request body before verifying if a valid
server action is received. This results in an "Error: Connection Closed"
error being thrown, rather than ignoring the action and failing more
gracefully
### Why?
To support progressive enhancement with form actions, the `actionId`
value is added as a hidden input in the form, so the action ID from the
header shouldn't be verified until determining that we've reached the
non-PE case. ([React
ref](https://github.com/facebook/react/pull/26774)). However, in
https://github.com/vercel/next.js/pull/49187, support was added for a
URL encoded form (which is not currently used, as indicated on the PR).
Despite it not being used for server actions, it's currently possible to
trigger this codepath, ie by calling redirect in an action handler with
a 307/308 status code with some data in the URL. This would result in a
500 error.
### How?
React should not attempt to parse the URL encoded form data until after
we've verified the server action header for the non-PE case.
x-ref NEXT-1733
[Slack
context](https://vercel.slack.com/archives/C03S8ED1DKM/p1700674895218399?thread_ts=1700060786.749079&cid=C03S8ED1DKM)
### What?
A `redirect` that occurs during a fetch action will get a status code of
200, while the redirection logic is handled client-side.
### Why?
In this scenario, the redirect is handled by the client router, so no
`Location` is set on the action response. However for debugging /
logging purposes, it'd be useful to still return the same status code
used in other cases (see #58885)
### How?
Rather than selectively setting the status to 303 in the non-fetch
action case, this always applies it.
Closes NEXT-1745
If a build time fetch cache is present from a previous build we don't
want to unexpectedly use it when flush to disk is set to false in a
successive build as it can leverage stale data unexpectedly.
x-ref: [slack
thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1701266754905909)
Closes NEXT-1750
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What?
Calling `redirect` or `permanentRedirect` with a route handler used by a server action will result in that POST request following the redirect. This could result in unexpected behavior, such as re-submitting an action (in the case where the redirected URL makes use of the same server action).
### Why?
By spec, 307 and 308 status codes will attempt to reuse the original request method & body on the redirected URL.
### How?
In all cases when calling a `redirect` handler inside of an action, we'll return a `303 See Other` response which is a typical status code when redirecting to a success / confirmation page as a result of a POST/PUT.
The other option would be to use 301 / 302 status codes, but since we're already doing a 303 status code [here](https://github.com/vercel/next.js/blob/canary/packages/next/src/server/app-render/action-handler.ts#L603), this aligns the behavior for the route handler case.
Closes NEXT-1733
See also: https://github.com/vercel/next.js/issues/51592#issuecomment-1810212676
[Slack x-ref](https://vercel.slack.com/archives/C03S8ED1DKM/p1700060786749079)
### What?
When the router action queue receives a bunch of async actions in quick succession, some of those requests are dropped, and as a result, anything observing pending transitions will be stuck in a pending state.
### Why?
When adding items to the action queue, the intended behavior is for new actions to be added to the end of the action queue, to be picked up by `runRemainingActions` once the in-flight action is processed. However, new actions are erroneously overwriting pending actions in the queue rather than appending them, as `actionQueue.last` might have a pending action attached to it.
### How?
This moves the assignment of `actionQueue.last` to always be in `dispatchAction`, rather than the function that processes the action, so that we always have a single spot where `last` is assigned and to prevent it from erroneously omitted/overwritten.
Fixes#59011
### What?
Bump up turbopack which includes url rewrite related improvements. This makes `test/integration/url` test passes.
Note there are some lacking behavior around edge runtime + url behavior, it is being tracked in PACK-2014.
Closes PACK-2051
### What?
We currently dedupe fetch requests, but if those fetch requests contain a `revalidate` time, when that window is expired all of those fetches will be invoked without deduping.
### Why?
We track revalidations on the `staticGenerationStore` but we don't have a way to dedupe them, as it's currently just an array. When the (patched) fetch is invoked and catches a stale entry, it'll push each fetch onto the `pendingRevalidates` array which will later be invoked via `Promise.all`.
### How?
This updates the shape of `pendingRevalidates` to be a map, that way we can reliably dedupe if we see a key that is already pending revalidation.
Closes NEXT-1744
[slack x-ref](https://vercel.slack.com/archives/C03S8ED1DKM/p1700836529460289)
Utils `stringToUint8Array` and `arrayBufferToString` assume that the values are just arbitrary fixed width data. However that doesn't work when we do unicode concatenation (`actionId + arg`) which requires Text encoder/decoder to be used.
Closes#58463, closes#58579. In general any complex unicode characters will cause the same issue, for example emojis.
## What?
Was investigating an issue with Turbopack and MDX, in the process found
a few bugs:
- When you have a `tsconfig.json` or `jsconfig.json` the `baseUrl: '.'`
is used by default which causes the top-level directories to be
available as e.g. `design-system` (without a prefix).
- This is not how TypeScript's default setting for `baseUrl` works.
While it should resolve `paths` relative to `.` when none is specified
it does not do additional resolving for the top level directories/files.
- When `"baseUrl": "."` is added to `tsconfig.js` explicitly it handles
the top level directories.
- `modularizeImports` and other SWC transforms weren't applied to `.mdx`
files when `experimental.mdxRs` is enabled, which caused compilation to
fail.
- `modularIzeImports` and other SWC transforms are not applied to `.mdx`
files when using Turbopack.
- @kwonoj is investigating this, will be handled in a follow-up PR.
## How?
- Added a test suite for `modularizeImports` with MDX tests
- Removed the condition that disables swcLoader in webpack when using
mdxRs
- Changed the check for `tsconfig.json` / `jsconfig.json` baseUrl to
include if it was implicitly or explicitly set, disabled the module
resolving when it is implicitly set
<!-- 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: Tobias Koppers <tobias.koppers@googlemail.com>
There're some reports related to using incorrect Node.js version, sometimes users ended up in weird errors. As pkg manager like pnpm only gives a warning ` WARN Unsupported engine: wanted: {"node":">=18.17.0"} (current: {"node":"v16.18.0","pnpm":"8.9.0"})` which is not easy to investigate the issue.
We're adding a version check at the beginning of the Next.js process so if Node.js version is mis-match the version specified in package.json, bail with error.
Examples
node 16.x
```
You are using Node.js 16.18.0. Node.js >= v18.17.0 is required.
```
node.18.16
```
You are using Node.js 18.16.1. Node.js >= v18.17.0 is required.
```
### What?
We can use the GitHub actions artifact (which is already produced right
now) instead of a separate git branch to get the latest test results.
This also means we don't have a dependency back to the turbo repo for
the daily tests.
Closes PACK-1951
We have identical `resetProject` code used in `bench/vercel` and our e2e workflow action -- this updates the `resetProject` script to side-effects free (hence removing the env var) and shared between bench & e2e
Closes NEXT-1731
