Excludes `/_next/image` and `/_next/static/media` as they don't contain sensitive information and prevents complications loading them in cases where they are inlined in CSS, as they'll be requested with `sec-fetch-mode: no-cors`.
x-ref: https://github.com/vercel/next.js/issues/77344
We have special development endpoints that are also prefixed under `/__nextjs`. This updates the origin checking logic to account for those in addition to `/_next`, and adds a test.
To avoid breaking local development proxies and more complex setups,
this ensures that we only block cross-origin development requests when
opting into the configuration. In a future major release, this will not
be opt-in, and will require explicitly providing the allowed origins
that can access the special `/_next` endpoints.
This adds a warning when a cross origin request is detected that would
be blocked without explicit configuration.
Fixes#77073Fixes#77253Fixes#77344
This ensures we don't allow cross-origin requests to be made to `/_next`
resources in dev mode. This matches existing handling that
webpack-dev-middleware does as well.
This PR removed the old overlay including the deprecated `buildActivity`
and `appIsrStatus` options.
Closes NDX-785
Closes NDX-855
Closes NDX-865
Closes NDX-866
Closes NDX-867
Closes NDX-868
- `newDevOverlay: true` by default (enables experimental React builds on
canary until owner stacks progress further)
- `run-tests` now sets the env var for tests that were relying on it for
forking behavior
- PPR runners now run with the flag disabled to help catch regressions
in the old overlay until we remove it
- Fixed a number of tests that had outdated snapshots or missed forking
behavior because they weren't running in CI
- Disabled a test that was failing in Turbopack + Experimental React
that is unrelated to the overlay (see:
https://github.com/vercel/next.js/pull/75989)
---------
Co-authored-by: devjiwonchoi <[email protected]>
The `--no-mangling` CLI option for `next build` was originally
introduced in #42633. However, we lost this feature during our migration
from Terser to SWC. As part of broader improvements for debugging
dynamic accesses with Dynamic I/O enabled, I needed this functionality
back, so I restored it for Webpack and also added it to Turbopack.
fixes#67037fixes#50208
---------
Co-authored-by: Benjamin Woodruff <[email protected]>
Currently, for `handleEntrypoints`, `handlePagesErrorRoute`,
`handleRouteType`, etc, both dev and prod use cases are combined into
the same functions. This leads to a lot of branching, use-case-specific
arguments, etc. for minimal opportunity for shared code.
In a following PR, entrypoint writing for prod will be done through a
single napi call to rust, further branching the two versions.
This splits them formally, at the cost of duplicating a handful of lines
in each case. Perhaps in the future we can develop a better system for
sharing code, but this makes things far clearer and easier to maintain
in this moment.
Test Plan: CI
- Before, there was a separate AST traversal that collected `next-dynamic` imports
- Now, we use transitions (which are inserted by the existing next-custom-transform) to tell Turbopack about the next-dynamic imports
- Unlike Webpack (where the react-loadable identifiers are `path/to/parent-module -> ./imported-client`), Turbopack just uses the module id: `[project]/path/to/imported-client.js [app-client] (ecmascript, next/dynamic entry)`
- the `next-dynamic` transition only inserts the marker module (i.e. for the SSR `import()`)
- the `next-dynamic-client` transition inserts the marker module and changes the module context (used to get the client module name)
- Now, we use the correct `AvailabilityInfo` for the next/dynamic chunks to preload, and they are not explicitly emitted. If they are for some reason not the same chunks that are actually emitted for the dynamic import, you get a hard error. (Previously, they didn't use the same `AvailabilityInfo` as the real async chunks, so they usually bundled another copy of React, and also had a different chunk name hash)
- For Turbopack, react-loadable manifests are now scoped per page instead of globally
> [!NOTE]
> The "Test new tests for flakes" may fail due to the number of tests in
a single `hmr.test.ts` file.
> The follow-up stacks are to resolve the issue.
### Why?
Moved to a separate file to run the test in parallel.
> [!NOTE]
> The "Test new tests for flakes" may fail due to the number of tests in
a single `hmr.test.ts` file.
> The follow-up stacks are to resolve the issue.
### Why?
Moved to a separate file to run the test in parallel.
> [!NOTE]
> The "Test new tests for flakes" may fail due to the number of tests in
a single `hmr.test.ts` file.
> The follow-up stacks are to resolve the issue.
### Why?
Moved to a separate file to run the test in parallel.
> [!NOTE]
> The "Test new tests for flakes" may fail due to the number of tests in
a single `hmr.test.ts` file.
> The follow-up stacks are to resolve the issue.
### Why?
Moved to a separate file to run the test in parallel.
> [!NOTE]
> The "Test new tests for flakes" may fail due to the number of tests in
a single `hmr.test.ts` file.
> The follow-up stacks are to resolve the issue.
### Why?
The test util `check` is deprecated internally, recommended to replace
to `retry`.
### What?
Add a new turbo-tasks backend that stores data normalized and is
prepared for persistent caching.
No longer keeps state in task locals, but all state is stored
immediately. This is required for persistent caching since it could
store and resume at any point and we always need to be in a valid state.
Tasks stay dirty until recomputed. (Previously dirty was changed to
scheduled)
### Why?
* Reduced memory usage
* preparation for persistent caching
### What?
The normal file watcher doesn't work inside a docker container, the
workaround is to enable a polling file watcher, which was supported in
webpack but not turbopack so far.
This PR adds support for a polling file watcher to turbopack and a
`next.config.js` option to configure the polling file watcher for both
webpack and turbopack.
Unfortunately, the rust file watcher seems to be a lot slower than the
poll interval.
Closes PACK-3206
Fixes#68255
Pages router (`/pages`) will continue to support React 18 not the React
19 RC. Current thinking is that we'll add support for React 19 in Pages
Router once 19 is stable.
This does not affect App Router (`/app`) which continues to use the
latest React Canary (i.e. React 19).
https://github.com/vercel/next.js/pull/65058 is required reading to
understand the changes in this PR
---------
Co-authored-by: Zack Tanner <[email protected]>
## What?
This implements passing the browerslist config from Next.js to
Turbopack. Initially I implemented passing the user browserslist config
in this PR as well but found that when this is lowered it causes test
failures, those need to be investigated separately but shouldn't block
these changes landing.
<!-- 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 #
-->
`StyledComponentsTransformConfig` should've used `#[serde(default)]` to
allow the user to provide a partial object with only some of the fields.
https://serde.rs/container-attrs.html#default
> When deserializing, any missing fields should be filled in from the
struct's implementation of `Default`. Only allowed on structs.
Without that, when serde tries to deserialize, it is expecting that the
object has all of it's fields filled in, and breaks because you've only
got two of them. The test suite only ever tested `styledComponents:
true` (not using an object), so it missed this.
## Test Plan
```
pnpm swc-build-native
TURBOPACK=1 TURBOPACK_DEV=1 pnpm test test/development/basic/styled-components
```
This work introduces the new concept of **Partial Fallback Prerendering
(PFPR)**.
Traditionally, when a dynamic page needed to be routed to that wasn't
pregenerated, it required a render to generate even the first few bytes
of the static page itself. This resulted in slow page loads for pages
not frequently visited and a reduced Time to First Byte (TTFB) score on
Core Web Vitals (CWV).
PFPR takes advantage of the new systems of Partial Prerendering (PPR)
that allows the application to suspend at different points mid-render,
and resume it later. We mark any unknown parameter access as dynamic
access, and suspend the rendering up to the next suspense boundaries at
those points. Under ideal conditions (correctly placed `<Suspense />`
boundaries or `loading.jsx` files) this generates a static shell that
can be served to users as soon as the request hits Next.js, right out of
the static cache. This minimizes the TTFB for all requests, dynamic or
not for those pages that enable PPR. For example, the following page
would create a usable shell:
```jsx
// /app/users/[userID]/page.jsx
import { Suspense } from 'react'
function Profile({ params }) {
const { userID } = params
return <div>Hello {userID}!</div>
}
export default function ProfilePage({ params }) {
return (
<div>
<h1>User Profile</h1>
<Suspense fallback="Loading...">
<Profile params={params} />
</Suspense>
</div>
)
}
```
Due to the way that suspense works within React components, access of
params within the root page component would cause the whole page to
suspend. Thankfully, that's where the `loading.jsx` comes in handy.
Adding a `loading.jsx` at a segment will automatically wrap the
`page.jsx` with a suspense boundary, setting the contents of the root
`loading.jsx` as the fallback component to use for it. This lets you
maintain your existing style of accessing parameters at the root of the
components while also taking advantage of PFPR.
To enable this feature, you first need to enable both PPR and PFPR:
```js
module.exports = {
experimental: {
ppr: true,
pprFallbacks: true,
}
}
```
Once PFPR has stabilized with hosting providers, the experimental flag
will go away and it will become the default with the PPR flag.
This PR fixes two issues with the use of `assetPrefix`:
#1: https://github.com/vercel/next.js/issues/64710
`assetPrefix` needs to be handled in `dev`, `deploy`, and `start`. In
the current approach, only `dev` and `start` were handled, but a quirk
of the implementation caused rewrites for non-asset paths to not be able
to be used in `afterFiles` rewrites.
#2: When deploying Next.js (such as on Vercel), you need to add your own
`beforeFiles` rewrite for `/${assetPrefix}/_next/...` requests or
otherwise they would 404.
This PR creates an automatically added `rewrite` to `beforeFiles` that
handles the case for `dev`, `start`, and `deploy`, removes the existing
logic in `filesystem.ts`, and adds more tests to check the behavior.
It’s possible to the following scenario to occur:
- Browser loads a page and establishes HMR connection
- User quits the server, makes changes, and restarts the server
- The browser reloads, the user makes more changes, and the two reach an
inconsistent state
To avoid this, reload the browser when the server changes. This already
happened with webpack, so implement it for Turbopack.
Test Plan: `TURBOPACK=1 pnpm test-dev
test/development/basic/hmr.test.ts`
---------
Co-authored-by: Tobias Koppers <[email protected]>
## What?
Removes the warning shown in Pages Router when you use the `prefetch`
prop on `next/link`. In App Router using `prefetch={true}` opts in to
full page prefetching even when the route is dynamically rendered.
When you're working on an application that uses both pages router and
app router where the components are shared using `<Link prefetch>` would
then cause this warning in Pages Router but not in App Router.
With this change there won't be a warning in Pages Router.
<!-- 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 <[email protected]>
<!-- 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 #
-->
### Fixing a bug
fixes#63820fixes#55320fixes#52931
In one of the issues, there was a suggestion to delete `assetPrefix`
from `next.config`. It helps if you have `assetPrefix: '/'`. Otherwise,
you probably won't face this problem.
**Explanation:**
The problem lies where the browser tries to connect and where websocket
is available on the server.
Adjust the condition for `prefix` in `get-socket-url` as it can return
`''` which will lead to `//` in the url.
The browser wants to connect to `ws://localhost:3000/_next/webpack-hmr`
While internally next exposes the web socket under
`ws://localhost:3000//_next/webpack-hmr` - you can connect to it via
wscat, postman or whatever.
As the path is different it does not handle HMR requests in the browser.
In addition to that - Reuse logic and extract separate files as a helper
in shared/lib.
| Before | After |
| ------ | ------- |
| 
before - latest canary branch - we can't establish a connection to HMR
ws |
same example with local changes - connected to ws |
---------
Co-authored-by: Jiwon Choi <[email protected]>
Co-authored-by: JJ Kasper <[email protected]>
...with `assertHasRedbox` and `assertNoRedbox`.
`hasRedbox()` has a hardcoded timeout of 5s that is only required for
the negative assertion.
Instead, we now have dedicated assertions for the positive
(`assertHasRedbox`) and negative case (`assertNoRedbox`).
The negative assertion still has the hardcoded timeout.
But the positive assertion just retries until we find the Redbox.
This speeds up tests using the positive assertion.
Removing `hasRedbox` also uncovered some unused expressions e.g. `await
hasRedbox(browser)`.
These expressions probably wanted to use `expect(await
hasRedbox(browser)).toBe(true)
### 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
* 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 <[email protected]>
