The warnings are fixed by callsite not by something changing an
abstraction on top of it. That's at least what the codemod assumes.
Basically each warning is now mapped to a change the codemod should've
made but didn't to avoid false-positives (e.g. propagating `async`
across module boundaries).
For browser specific access we don't dedupe since we have no
`React.cache`
### 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
Next.js has a number of dynamic APIs that aren't available during
prerendering. What happens when you access these APIs might differ
depending on the mode you are using, for instance if you have PPR turned
on or the newly introduced `dynamicIO` experimental mode. But regardless
of the mode the underlying API represents accessing something that might
only be available at render time (dynamic rendering) rather than
prerender time (build and revalidate rendering)
Unfortunately our current dynamic APIs make certain kinds of modeling
tricky because they are all synchronous. For instance if we wanted to
add a feature to Next.js where we started a dynamic render before a
Request even hits the server it would be interesting to be able to start
working on everything that does not rely on any dynamic data and then
once a real Request arrives we can continue the render and provide the
associated Request context through our dynamic APIs.
If our dynamic APIs were all async we could build something like this
because they represnt a value that will eventually resolve to some
Request value. This PR updates most existing dynamic APIs to be async
rather than sync. This is a breaking change and will need to be paired
with codemods to realistically adopt. Additionally since this change is
so invasive I have implemented it in a way to maximize backward
compatibility by still allowing most synchronous access. The combination
of codemods, typescript updates, and backward compat functionality
should make it possible for projects to upgrade to the latest version
with minimal effort and then follow up with a complete conversion over
time.
#### `cookies()`
`cookies()` now returns `Promise<ReadonlyRequestCookies>`. Synchronous
access to the underlying RequestCookies object is still supported to
facilitate migration.
```tsx
// ------------ preferred usage
// async Server Component
const token = (await cookies()).get('token')
// sync Server Component
import { use } from 'react'
//...
const token = use(cookies()).get('token')
// ------------ temporarily allowed usage
// javascript, dev warning at runtime
const token = cookies().get('token')
// typescript, dev warning at runtime
import { type UnsafeUnwrappedCookies } from 'next/headers'
// ...
const token = (cookies() as unknown as UnsafeUnwrappedCookies).get('token')
```
#### `headers()`
`headers()` now returns `Promise<ReadonlyHeaders>`. Synchronous access
to the underlying Headers object is still supported to facilitate
migration.
```tsx
// ------------ preferred usage
// async Server Component
const header = (await headers()).get('x-foo')
// sync Server Component
import { use } from 'react'
//...
const header = use(headers()).get('x-foo')
// ------------ temporarily allowed usage
// javascript, dev warning at runtime
const header = headers().get('x-foo')
// typescript, dev warning at runtime
import { type UnsafeUnwrappedHeaders } from 'next/headers'
// ...
const header = (headers() as unknown as UnsafeUnwrappedHeaders).get('x-foo')
```
#### `draftMode()`
`draftMode()` now returns `Promise<DraftMode>`. Synchronous access to
the underlying DraftMode object is still supported to facilitate
migration.
```tsx
// ------------ preferred usage
// async Server Component
if ((await draftMode()).isEnabled) { ... }
// sync Server Component
import { use } from 'react'
//...
if (use(draftMode()).isEnabled) { ... }
// ------------ temporarily allowed usage
// javascript, dev warning at runtime
if (draftMode().isEnabled) { ... }
// typescript, dev warning at runtime
import { type UnsafeUnwrappedDraftMode} from 'next/headers'
// ...
if ((draftMode() as unknown as UnsafeUnwrappedDraftMode).isEnabled) { ... }
```
#### `searchParams`
`searchParams` is now a `Promise<{...}>`. Synchronous access to the
underlying search params is still supported to facilitate migration.
```tsx
// ------------ preferred usage
// async Page Component
export default async function Page({
searchParams
}: {
searchParams: Promise<{ foo: string }>
}) {
const fooSearchParam = (await searchParams).foo
}
// sync Page Component
import { use } from 'react'
export default function Page({
searchParams
}: {
searchParams: Promise<{ foo: string }>
}) {
const fooSearchParam = use(searchParams).foo
}
// ------------ temporarily allowed usage
// javascript, dev warning at runtime
export default async function Page({ searchParams}) {
const fooSearchParam = searchParams.foo
}
// typescript, dev warning at runtime
import { type UnsafeUnwrappedSearchParams } from 'next/server'
export default async function Page({
searchParams
}: {
searchParams: Promise<{ foo: string }>
}) {
const syncSearchParams = (searchParams as unknown as UnsafeUnwrappedSearchParams<typeof searchParams>)
const fooSearchParam = syncSearchParams.foo
}
```
#### `params`
`params` is now a `Promise<{...}>`. Synchronous access to the underlying
params is still supported to facilitate migration. It should be noted
that while params are not usually dynamic there are certain modes where
they can be such as fallback prerenders for PPR.
```tsx
// ------------ preferred usage
// async Segment Component
export default async function Layout({
params
}: {
params: Promise<{ foo: string }>
}) {
const fooParam = (await params).foo
}
// sync Segment Component
import { use } from 'react'
export default function Layout({
params
}: {
params: Promise<{ foo: string }>
}) {
const fooParam = use(params).foo
}
// ------------ temporarily allowed usage
// javascript, dev warning at runtime
export default async function Layout({ params}) {
const fooParam = params.foo
}
// typescript, dev warning at runtime
import { type UnsafeUnwrappedParams } from 'next/headers'
export default async function Layout({
params
}: {
params: Promise<{ foo: string }>
}) {
const syncParams = (params as unknown as UnsafeUnwrappedParams<typeof params>)
const fooSearchParam = syncParams.foo
}
```
### Typescript Changes
When using typescript with Next.js currently it is up to you to author
types for Pages, Layouts and other Segment components that recieve props
like `params` and `searchParams`.
Next comes with some build-time type checking to ensure you have not
improperly typed various top level module exports however the current
type assertions for `params` and `searchParams` is `any`. This isn't
very helpful because it allows you to erroneously type these props.
`searchParams` is tricky because while the default type is a dictionary
object parsed using node.js url parsing it is possible to customize when
running a custom Next.js server. However we can ensure that you
correctly type the prop as a Promise so with this change the validated
type for `searchParams` will be `Promise<any>`.
In the long run we will look at updating the `searchParams` underlying
type to be URLSearchParams so we can move away from supporting
customized parsing during rendering and we can get even more explicit
about valid types.
`params` is more straight forward because the framework controls the
actual `params` prop implementation and no customization is possible. In
the long run we want to enforce you are only typing params that are
valid for the Layout level your file is located in but for now we are
updating the allowed type to be `Promise<{[key: string]: string |
string[] | undefined }>`.
These new type restrictions may also require fixes before being able to
successfully build a project that updates to include these breaking
changes. These changes will also not always be codemodable because it is
valid to type the entire component using an opaque type like `Props`
which our codemods may not have an ability to introspect or modify.
fixes a race condition in the `after()`-related test in
`server-components-hmr-cache.test.ts`
i made `getLoggedAfterValue` stricter while investigating an unrelated
issue, and saw it occasionally throw (see [CI
run](https://github.com/vercel/next.js/actions/runs/11001754094/job/30547234764?pr=70362#step:29:708)).
before this change, if `getLoggedAfterValue` was called before any logs
with `"After: "` were written, it would just return `undefined`, which
is obviously not what the test wants. this seems to have been happening
occasionally, but it wasn't visible because even if we got `undefined`
from one of the calls, the
`expect(valueBeforePatch).not.toEqual(valueAfterPatch)` assertion would
still pass -- one of the values is a string and the other is
`undefined`, so obviously they're not equal!
The TypeScript error `Props must be serializable for components in the
"use client" entry file, "reset" is invalid.` for the `reset` prop in
`error.tsx` and `global-error.tsx` was fixed in #46898 and #48756,
respectively. However, a regression of the fix was accidentally
introduced in #67211.
This PR restores the previous behavior and adds fixtures for manual
testing. (Since the Next.js TS plugin only applies to VSCode, manual
testing in VSCode is required. See
[`test/development/typescript-plugin/README.md`](https://github.com/vercel/next.js/blob/a5f30e68f8d1fe614965abc5df0234a869c6db8a/test/development/typescript-plugin/README.md)
for details.)
### What?
Improve error messages about invalid CSS files.
### Why?
Currently, `sass-loader` compiles CSS as a single line, and as the issue
emitter prints the whole line, the error message is not good.
### How?
Closes PACK-3187
Fixes#68311
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Closes#69861
Closes PACK-3240
The sourcemaps of server actions were invalid, the listed source file
was the file `AssetIdent` like
`turbopack://[project]/bench/basic-app/app/actions.ts [app-client]
(ecmascript, action)` instead of only the source file path.
This broke the sourcemap mapping logic of the error overlay.
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
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 <1939140+ztanner@users.noreply.github.com>
## 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 #
-->
`unstable_after` needs to be tested in both nodejs and edge runtimes.
Previously, we set the runtime via `next.patch()`, but this proved
error-prone (e.g. because `sandbox()` call would override this patch,
and not actually run anything in edge...)
This PR makes this more static by splitting the test pages for
`unstable_after` into `/nodejs` and `/edge`, each with a corresponding
`export const runtime = "..."` in its root layout. The pages in `/edge`
mirror the structure of `/nodejs` and reexport components from it (which
makes the tests easier to update than simply duplicating everything).
note that "use client" directives and route segment configs cannot be
reexported and need to be duplicated.
`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
```
`nextConfig.experimental.dynamicIO: boolean` is a new experimental flag
that changes the static generation bailout heuristic and PPR postpone
heuristic to exclude async work that is not resolvable in the current
Task's microtask queue from prerenders. functionally it means that in
this mode fetches and db queries will now not be prerenderable unless
you opt into it with a caching API like `unstable_cache()` or the fetch
`cache: 'force-cache'` option.
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.
### Why?
In https://github.com/vercel/next.js/pull/68622 we fixed a bug that HMR
breaks when `assetPrefix` is set to full URL.
The fix was targeted to the edge case where the user may set `localhost`
to the `assetPrefix`, and technically, when the request is valid the HMR
should work.
However, we do not recommend this pattern as the `assetPrefix` is
intended to be used for setting a CDN URL.
### How?
Therefore we modify the docs to gently imply that the `assetPrefix` is
for CDN URL.
Also, removed the warning log that could be confusing whether we support
it or not.
Setting localhost will still work, but we do not mention about it within
the app.
Currently we only log warnings when we fail to parse config values and
then fall back to their defaults, this is very dangerous as this can
cause unexpected behavior and the warning log can be easy to miss. To
prevent this unexpected behavior this updates to treat these as errors
instead and fails the build if any invalid config exports are provided.
x-ref: NDX-190
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 <tobias.koppers@googlemail.com>
### What?
Disables logging when an error is thrown anyway (which will be logged
upstream).
Reduces the errors logged when there is a compiler error to 1, currently
it shows 3 times.
Closes PACK-3170
This moves the static indicator we added for the app router into the dev
overlay so it can share the logic/be aware when either are showing to
coordinate position. This also applies similar design to make the look
more consistent as well.
https://github.com/user-attachments/assets/bca899d4-0635-4868-8284-02f0cb4b5444
Closes: NDX-74
## 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 <jj@jjsweb.site>
While we currently refetch RSC updates on changes to the environment
(e.g. `.env` files), we never cleared the require cache to re-evaluate
RSCs with the new environment. This implements that.
Test Plan: Added tests. `TURBOPACK=1 pnpm test-dev
test/development/app-hmr/hmr.test.ts`
<!-- 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 <devjiwonchoi@gmail.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Zack Tanner