As mentioned in the new-added error messages, and the [linked
resources](https://react.dev/reference/react/use-server#:~:text=Because%20the%20underlying%20network%20calls%20are%20always%20asynchronous%2C%20%27use%20server%27%20can%20only%20be%20used%20on%20async%20functions.):
> Because the underlying network calls are always asynchronous, 'use
server' can only be used on async functions.
> https://react.dev/reference/react/use-server
It's a requirement that only async functions are allowed to be exported
and annotated with `'use server'`. Currently, we already have compiler
check so this will already error:
```js
'use server'
export function foo () {} // missing async
```
However, since exported values can be very dynamic the compiler can't
catch all mistakes like that. We also have a runtime check for all
exports in a `'use server'` function, but it only covers `typeof value
=== 'function'`.
This PR adds a stricter check for "use server" annotated values to also
make sure they're async functions (`value.constructor.name ===
'AsyncFunction'`).
That said, there are still cases like synchronously returning a promise
to make a function "async", but it's still very different by definition.
For example:
```js
const f = async () => { throw 1; return 1 }
const g = () => { throw 1; return Promise.resolve(1) }
```
Where `g()` can be synchronously caught (`try { g() } catch {}`) but
`f()` can't even if they have the same types. If we allow `g` to be a
Server Action, this behavior is no longer always true but depending on
where it's called (server or client).
Closes#62727.
### What?
* upgrades turbopack for `getResolve` in webpack loaders
* add missing resolve-url-loader to turbopack for full sass support
Closes PACK-2634
## Description
Refactor the [Next.js
CLI](https://nextjs.org/docs/app/api-reference/next-cli) to use
[commander](https://github.com/tj/commander.js) instead of
[arg](https://github.com/vercel/arg).
## Why?
- Auto-generated, properly formatted help command + output. With `arg`,
much of the help commands were manually added via a single
`console.log`, causing deviations over time.
- Ergonomic, ease of adding new subcommands and rules
## Breaking Changes
- Update the experimental `next experimental-compile` and `next
experimental-generate` build commands in favor of `next build
--experimental-build-mode=compile/generate`
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
## What?
Working on fixing `test/e2e/conflicting-app-page-error`, this adds a
compiler error for the case where App Router routes conflict with Pages
Router routes. It's not 1:1 the same error as in webpack because in the
webpack version we hijacked the App Router resolving logic to assume
there's a certain set of paths, where Turbopack has the full route to
route tree resolving implementation which doesn't assume there's a
single page that can be resolved.
The tests are updated to reflect this change.
<!-- 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-2592
## What?
Migrates the Sass support tests from `test/integration` (legacy test
suite) to `test/e2e`, this way all these tests run against both
development and production, whereas previously most of them would only
run against production.
This is helpful as it ensures the tests are running against Turbopack
too, which is highlighting some missing features in Sass support for
Turbopack.
I've had to rewrite most of the tests to check against the actual
rendered output in the browser instead of CSS output in the `.next`
folder, the majority of these now run regardless of implementation
details.
<details>
<summary>Tests that failed with Turbopack</summary>
```
FAIL e2e/app-dir/scss/url-global-partial/url-global-partial.test.ts (84.9 s)
● SCSS Support loader handling › CSS URL via file-loader sass partial › should render the page
thrown: "Exceeded timeout of 60000 ms for a test.
Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."
13 | })
14 |
> 15 | it('should render the page', async () => {
| ^
16 | const browser = await next.browser('/')
17 | expect(
18 | await browser.elementByCss('.red-text').getComputedCss('color')
at it (e2e/app-dir/scss/url-global-partial/url-global-partial.test.ts:15:5)
at describe (e2e/app-dir/scss/url-global-partial/url-global-partial.test.ts:7:3)
at Object.describe (e2e/app-dir/scss/url-global-partial/url-global-partial.test.ts:6:1)
FAIL e2e/app-dir/scss/composes-external/composes-external.test.ts (84.765 s)
● CSS Module Composes Usage (External) › should render the module
thrown: "Exceeded timeout of 60000 ms for a test.
Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."
12 | })
13 |
> 14 | it('should render the module', async () => {
| ^
15 | const browser = await next.browser('/')
16 | expect(
17 | await browser.elementByCss('#verify-yellow').getComputedCss('color')
at it (e2e/app-dir/scss/composes-external/composes-external.test.ts:14:3)
at Object.describe (e2e/app-dir/scss/composes-external/composes-external.test.ts:6:1)
FAIL e2e/app-dir/scss/composes-basic/composes-basic.test.ts (35.629 s)
● CSS Module Composes Usage (Basic) › should render the module
expect(received).toBe(expected) // Object.is equality
Expected: "rgb(255, 255, 0)"
Received: "rgb(0, 0, 0)"
16 | expect(
17 | await browser.elementByCss('#verify-yellow').getComputedCss('color')
> 18 | ).toBe(colorToRgb('yellow'))
| ^
19 | expect(
20 | await browser
21 | .elementByCss('#verify-yellow')
at Object.toBe (e2e/app-dir/scss/composes-basic/composes-basic.test.ts:18:7)
FAIL e2e/app-dir/scss/npm-import-nested/npm-import-nested.test.ts (90.889 s)
● Good Nested CSS Import from node_modules › should render the page
thrown: "Exceeded timeout of 60000 ms for a test.
Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."
12 | })
13 |
> 14 | it('should render the page', async () => {
| ^
15 | const browser = await next.browser('/')
16 | expect(
17 | await browser.elementByCss('.red-text').getComputedCss('color')
at it (e2e/app-dir/scss/npm-import-nested/npm-import-nested.test.ts:14:3)
at Object.describe (e2e/app-dir/scss/npm-import-nested/npm-import-nested.test.ts:6:1)
FAIL e2e/app-dir/scss/nm-module-nested/nm-module-nested.test.ts (81.941 s)
● Valid Nested CSS Module Usage from within node_modules › should render the page
thrown: "Exceeded timeout of 60000 ms for a test.
Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."
12 | })
13 |
> 14 | it('should render the page', async () => {
| ^
15 | const browser = await next.browser('/')
16 | expect(await browser.elementByCss('#other2').getComputedCss('color')).toBe(
17 | colorToRgb('red')
at it (e2e/app-dir/scss/nm-module-nested/nm-module-nested.test.ts:14:3)
at Object.describe (e2e/app-dir/scss/nm-module-nested/nm-module-nested.test.ts:6:1)
```
</details>
<!-- 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-2550
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
## What?
#62528 caused test/e2e/app-dir/not-found/conflict-route to fail
compilation in Turbopack, this compiler error was previously already
reported by Turbopack but Next.js didn't show it, which #62528 resolved.
This PR changes the handling for the not-found handling to be consistent
between development and build, which ensures that the "special" page no
longer conflicts with app/not-found/page.js.
Closes NEXT-2617
Note: this is a reworked iteration of
https://github.com/vercel/next.js/pull/62585 which wasn't sufficient.
<!-- 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?
Do not fail when `useSelectedLayoutSegment` or
`useSelectedLayoutSegments` APIs are called in the Pages Router.
### Why?
This makes migration easier and creates consistency with our other App
Router-specific APIs that inherit the same behavior.
### How?
Similar to #47490, we return `null` if there is no Layout context
(indicating being in Pages Router)
Types are also overridden in the navigation compact module declaration
which kicks in during start to correct the types if we detect a `pages/`
directory.
Note to reviewer: #47490 didn't add a test, so I added one top-level,
let me know if you have a better suggestion for placing.
Closes NEXT-2506
Fixes#61464
### What?
Fixes https://github.com/vercel/next.js/issues/62525
Closes NEXT-2620
Since codes below do not consider searchParams, `redirect` in server
action removes all searchParams passed from client side.
93e4bb823c (diff-c809d50461027cdba7c092e564818b1172133d337abc5c513f829c94c8483dc6R186)
So I just add conditional branch for searchParams.
---
lint, prettier was applied.
Also I have done tests by commands below. and it was all passed.
```
pnpm testonly --testPathPattern "integration" -t "redirect"
```
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What?
generateSitemaps function returns a 404 for /sitemap/[id].xml in
production
### Why?
While finding the correct sitemap partition from the array, we check the
param against the id. Which works in dev because id and param are both
without trailing .xml. But it fails in production as param has a
trailing .xml (/sitemap/[id] works in production because it falls back
to dynamic loading and param and id are both without .xml)
### How?
If we are in production environment, check the id with a trailing .xml
because that's whats returned from generateStaticParams, an array of
__metadata_id__ with trailing .xml
Fixes#61969
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
This moves the locale redirect handling out of `base-server` as it
shouldn't be handled here and should be at the routing level. This
avoids the duplicate handling with middleware that causes the incorrect
detection/infinite looping. Test case from separate PR was carried over
to prevent regression.
Fixes: https://github.com/vercel/next.js/issues/55648
Closes: https://github.com/vercel/next.js/pull/62435
Closes: NEXT-2627
Closes: NEXT-2628
---------
Co-authored-by: Nourman Hajar <nourmanhajar@gmail.com>
Co-authored-by: samcx <sam@vercel.com>
### What
Change from processing the file with `next-metatdata-route-loader`
directly into passing the file as loader query, and leave an empty
resource file for it. This will resolve the error that users were seeing
with `manifest.json` convention.
```
Import trace for requested module:
../../../../packages/next/dist/build/webpack/loaders/next-metadata-route-loader.js?page=%2Fmanifest.jso
n%2Froute&isDynamic=0!./app/manifest.json?__next_metadata_route__
getStaticAssetRouteCode page /manifest.json/route this.resourcePath /Users/huozhi/workspace/next.js/tes
t/e2e/app-dir/metadata-json-manifest/app/manifest.json
```
### Why
I looked at the loader process that the final resource processed by
webpack is `json!next-metadata-route-loader...`, which means the builtin
json loader processing json file after the metadata route loader. I
didn't get chance to solve the ordering issue, so I changed the
resourcePath to empty "", and pass the file path as query into the
loader to avoid json-loader processing it after transpilation.
Fixes#59923
Closes NEXT-2630
Closes NEXT-2439
This ensures our dynamic routes that have the same specificity as
`_next/static/:path*` don't get matched unexpectedly when the
`_next/static` asset doesn't exist. We were holding off on making this
change explicit due to compatibility concerns but these are no longer a
concern and the unexpected matching is more of a concern.
Closes: CSM-11
Fixes: https://github.com/vercel/next.js/issues/19270
Closes NEXT-2613
### What
Fixes `redirect()` call under suspense boundary, redirect url should
include the `basePath` in the url.
### Why
`redirect()` under suspense boundaries will go through server html
insertion, which is being used every time by suspense boundary resolved,
new errors will triggered from SSR streaming. It was missing before.
Fixes NEXT-2615
Fixes#62407
### What?
We should treat the warning for CSR bailout the same as the hard-error,
and show the stack trace for either case.
### Why?
It might be useful to track down the source of this warning.
### How?
We have the stack info already, but we only showed it during the error
logging. We should show it for warnings too.
This is similar to #61200
Closes NEXT-2624
### What
When the popstate action is fired (as is the case in a browser back
button), if the page you're going back to has missing cache node data,
the router will crash.
### Why
Almost all router actions will suspend at the app-router level with the
exception of `ACTION_RESTORE`. This was to address an issue where
suspending in the router would add enough delay for browser scroll
restoration behavior not to work.
As a result, when going back to the page with missing data, app-router
wouldn't suspend but layout-router would suspend on the missing data
while triggering a lazy fetch. We trigger a server-patch with the
applied lazy data, but when React replays the render, it will replay the
branch without the cache node data applied. This results in the router
getting caught in a loop of suspending, applying the cache node,
replaying the branch without the cache node, and eventually crashing due
to an error thrown by React to prevent re-suspending indefinitely.
### How
This adds a property to the cache node to signal if the lazy data has
been resolved. If it has been, we won't call the server patch action
again.
Fixes#61336
Closes NEXT-2438
### What
Introduce a `react-server` export condition of `next/navigation`, which
only take effects in RSC layer. And it will only contain `notFound` and
`redirect` related APIs, which can be shared in both server components
and client components environment. This export excludes those APIs
working with React context which are only working in client components.
### Why
We fixed an issue bad alias for react-server condition of react itself
in
https://github.com/vercel/next.js/pull/61522/files#diff-ecb951c8d26893f6d1e4425a873b399d52346ef63eb90fba79d980cef2fabe8cL35
, this was a good fix. But we found that if you're using edge runtime
with `next/navigation` it will error with bundling that you're attempted
to import some client component hooks such as `useContext` from react.
So we introduced a `react-server` version of `next/navigation` that
doesn't interoplate with any client hooks, can we'll bundle that one
instead of original `next/navigation` when you're using it in server
components or app routes.
Closes NEXT-2583
Closes NEXT-2519
Fixes#62187
With Server Actions, a module-level encryption can happen when you do:
```js
function wrapAction(value) {
return async function () {
'use server'
console.log(value)
}
}
const action = wrapAction('some-module-level-encryption-value')
```
...as that action will be created when requiring this module, and it
contains an encrypted argument from its closure (`value`). This
currently throws an error during build:
```
Error: Missing manifest for Server Actions. This is a bug in Next.js
at d (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/chunks/1772.js:1:15202)
at f (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/chunks/1772.js:1:16917)
at 714 (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:2806)
at t (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/webpack-runtime.js:1:127)
at 7940 (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:941)
at t (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/webpack-runtime.js:1:127)
at r (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:4529)
at /Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:4572
at t.X (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/webpack-runtime.js:1:1181)
at /Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:4542
```
Because during module require phase, the encryption logic can't run as
it doesn't have Server/Client references available yet (which are set
during the rendering phase).
Since both references are global singletons to the server and are
already loaded early, this fix makes sure that they're registered via
`setReferenceManifestsSingleton` before requiring the module.
Closes NEXT-2579
This test case was added in #59752, but this doesn't seem like the
correct behavior.
The original PR was intended to be smart about resolving `/default.tsx`
to a route group default (e.g. `/(foo)/default.tsx`) when one wasn't
specified. But since the route group is creating a new hierarchy in the
tree and defines its own layout, if the route group layout doesn't
specify a default, then the not found behavior seems correct.
To fix unexpected not-found behavior in this case, you should specify a
default at the same level as the layout where the missing slot(s) might
be rendered.
Closes NEXT-2565
This onClick isn't actually being used by the test and seems to be
causing a flake unrelated to the test assertions. This removes the
unused code for now so we can still keep the relevant part of the test
in-tact. (Specifically, this test is asserting that we're using the
correct prefetch cache entry for interception routes that originate from
different trees but resolve to the same URL)
<!-- 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-2568
## Description
We need to manually update the `@capsizecss/metrics` every time it
updates so we get the latest fallback fonts.
## Changes
- https://github.com/vercel/next.js/issues/47115
Closes NEXT-2547
This adds a new span to allow tracking the sum of all client component
loading times for a specific request along with the count of items
loaded.
Closes NEXT-2540
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What
When a prefetch cache entry becomes "stale", it'll remain stale until
eventually it gets evicted. However during that stale window, the cache
is never revalidated, and so instant navigations stop working and data
is fetched from origin every navigation.
### Why
The `lastUsedTime` entry on the prefetch cache is currently only updated
after the first read. Once it becomes stale, `applyFlightData`'s
recursive functions will see that there is no longer a reusable prefetch
cache entry, and will trigger a lazy fetch of the new data on every
subsequent navigation.
### How
This updates prefetch cache handling to always ensure we’re using a
fresh or reusable prefetch cache entry. This means that stale prefetch
entries will be refreshed on a navigation event. As a result of this,
I’ve had to disable one of our tests that relies on this stale cache
behavior. It’s not ideal that we’re blocked on the loading boundary when
fetching child segment data—ideally we can refactor this to cache the
loading component in the CacheNode and copy it over on navigations,
similar to how ‘head’ is handled. I’ll work on this in a separate PR.
Note: The new client cache test for this is disabled in PPR for the same
reason as the other tests: auto prefetching with PPR navigations is
currently loading fresh data rather than reusing the prefetch cache.
Fixes#58969Fixes#58723
Closes NEXT-1904
### What & Why
This PR helps fixes a long time tree-shaking issue that if you're import
some identifiers from client components, the whole client component is
being included in the client chunk. Because we're using import eager
mode in webpack to include all the client component modules that make
sure they're present in SSR entry and browser entry when they're
transformed to client reference on RSC layer.
But the way we collect client components is a bit "aggressive" where
contains some spaces to optimize.
### How
We change the collected client components from simpliy collecting it
resolved module request, into collecting both the imported identifiers
(by server components) and the module request. And when we inserted the
used client components imports into the SSR and Client entry, leverage
webpack magic comments `"webpackExports"` to only contain the used
exports in the bundle. Thank you webpack for this nice feature : )
Along the way we also fixed an issue that when you only used default
export, the `default` export itself should also be proxied when the
bundle is in ESM.
#### Notice
There's a limitation yet that it can't work with barrel file, if you
have a shared component `index.js` to re-export the changes several
client components there and you only partially import few from
`index.js` it won't work. For the cases that the node_modules package
contain a barrel file importing multiple client components, please use
[optimizePackageImports](https://nextjs.org/docs/app/api-reference/next-config-js/optimizePackageImports)
config for now. We'll have follow up optimizations
### Testing Result
If we compare the `react-aria-components` the reproduction from #60246,
you'll see the result being optimized a lot:
#### After vs Before
134KB being tree-shaked out 🤯
```
Route (app) Size First Load JS
┌ ○ / 324 B 127 kB
├ ○ /_not-found 872 B 86.5 kB
└ ○ /other-page 174 B 127 kB
```
```
Route (app) Size First Load JS
┌ ○ / 325 B 261 kB
├ ○ /_not-found 870 B 86.5 kB
└ ○ /other-page 176 B 261 kB
```
Fixes#60246
Related report: https://github.com/adobe/react-spectrum/issues/5639
Closes NEXT-2527
phase 1 of NEXT-1799
---------
Co-authored-by: Shu Ding <g@shud.in>
### What?
Fix one assertion about CSS files emitted by turbopack.
### Why?
Turbopack generates `/_next/static/chunks/2225ce._.css`, which does not
match the regex.
Note that it has `._.css`. The previous assertions match on
`[^.]+\.css`, which does not support two dots in the file name.
I tried `/<link rel="stylesheet" href=".+\.css(\?v=\d+)?"/g`, but it
captured 3 `link` tags at once. So I used `/<link rel="stylesheet"
href="[^<]+\.css(\?v=\d+)?"/g`.
### How?
Closes PACK-2413
As discussed almost all webpack plugins shouldn't have issues with this
being enabled by default so removing the default condition where we
disable this optimization due to custom webpack config is more
beneficial and in the rare case a custom plugin has issues it can still
be manually disabled.
Closes NEXT-2523
### What?
* add support for esmExternals in pages
* fix default of esmExternals to true
* fix serverComponentExternalPackages support
* add test case
fixes PACK-2311
fixes PACK-1916
Fixes https://github.com/vercel/turbo/issues/4544
### What?
Fix one assertion about CSS files emitted by turbopack.
### Why?
Webpack generates 3 links with `?v=` query, and 2 extra links without
`?v=` query. Turbopack does not have query string, so we match 5 links.
### How?
Closes PACK-2414
### What
* Narrow down the metadata base warnings only when there's any relative
urls need to be resolved, if there's only absolute urls present, no need
to resolve and we don't warn.
* Polish the error message, updated from "metadata.metadataBase is not
set ..." to "metadataBase property in metadata export is not set ..."
### Why
It will be confusing if we're still show metadataBase warning when
there's no need to set one, since the social image cards only have
absolute urls
Closes NEXT-2426
### What
We should respect the `trailingSlash` config for metadata canonical url,
this PR is adding the handling for strip or keep the trailing slash for
canonical url. Passing down trailingSlash config to metadata resolving
to decide how we handle it.
### Why
The tricky one was `/` pathname, when visiting the origin directly, that
it will always have at least `/` in the URL instance. But for the
default `origin`, it shouldn't show the `/` if the `trailingSlash`
config is `false`. Also it should show trailing slash for all pathnames
if that config is enabled.
BTW there's a `__NEXT_TRAILING_SLASH` env but since we're using the
fixed nextjs runtime module, so this can't be dynamically replaced in
the metadata resolving modules. So we didn't use it
Fixes#54070
Closes NEXT-2424
### What
Following an anchor link to a hash param, and then attempting to use
`history.pushState` or `history.replaceState`, would result in an MPA
navigation to the targeted URL.
### Why
In #61822, a guard was added to prevent calling `ACTION_RESTORE` with a
missing tree, to match other call-sites where we do the same. This was
to prevent the app from crashing in the case where app router internals
weren't available in the history state. The original assumption was that
this is a rare / unlikely edge case. However the above scenario is a
very probable case where this can happen, and triggering an MPA
navigation isn't ideal.
### How
This updates `ACTION_RESTORE` to be resilient to an undefined router
state tree. When this happens, we'll still trigger the restore action to
sync params, but use the existing flight router state.
Closes NEXT-2502
