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
### What?
* scope issues from subscriptions to the websocket connection
* close subscriptions when closing the websocket connection
### Why?
* subscriptions on one page should not affect other pages
### How?
Closes PACK-2567
This adds an experimental flag to allow exiting during prerendering when
the first path errors instead of waiting until all prerendering is
finished to then fail the build.
x-ref: [slack
thread](https://vercel.slack.com/archives/C0676QZBWKS/p1708559793380989)
Closes: NEXT-2561
Closes NEXT-2563
### What?
Run 10 concurrent Turbopack compilation jobs instead of all of them
show a progress spinner
### Why?
* In future this allows to reclaim memory for finished jobs
* It looks nicer in tracing
Closes PACK-2561
### What?
Allow [typescript-eslint
v7](https://typescript-eslint.io/blog/announcing-typescript-eslint-v7)
support
### Why?
Allow compatibility with typescript eslint v7, pave the way to support
eslint flat config and possibly typescript 5.4
### How?
Add a v7 to the allowed versions in eslint-config-next dependencies and
regenerate the lock with pnpm install. Be aware that some eslint peer
dev deps have been updated in the process. See the lock
Tested with pnpm build && ppm lint
## Close
- Closes https://github.com/vercel/next.js/issues/62138
### What?
In today's implementation, requests that don't end in `.rsc` are getting
the data request query. We need to remove this toggle to prevent them
from 500'ing.
### Why?
The invariant triggered was:
212553958c/packages/next/src/server/base-server.ts (L2838-L2842)
Crawling up the code, the conditional:
212553958c/packages/next/src/server/base-server.ts (L2815)
must be `true`.
The variable `isDataReq` is set here:
212553958c/packages/next/src/server/base-server.ts (L1833-L1839)
This conditional expression is a bit complex, but it simplifies down to:
- `isDataReq` is `true` when (TODO)
- `isDataReq` is `false` when (TODO)
### How?
Closes NEXT-2341
Fixes#61377
Tested manually by:
- Building and packaging this branch locally
- Deploying tarball and then depending on it as the Next.js version for
an example app similar to the one reported by #61377
- Inspecting console for 500 errors.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
## 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
### What
This PR amends turbopack's behavior to handle some cases of normalized
path (`%5F` starting path), mainly fixes entry lookup works against
original path without normalization, also bends the output path of
client reference manifest matchs to what next.js expects.
Closes PACK-2553
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?
* Verify correctness of externals
* error when packages can't be made external
### Why?
* Resolving to incorrect externals might lead to runtime errors
* Give users hints how to fix these issues
### How?
Closes PACK-2535
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
### 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?
The [create-next-app
documentation](https://nextjs.org/docs/app/api-reference/create-next-app#non-interactive)
under API reference says that;
> Further, you can negate default options by prefixing them with --no-
(e.g., --no-eslint).
When I tried to use --no-import-alias, I thought that it would
automatically use the default alias (@/*), but it does not.
### Why?
Each option has --no prefix control but import-alias has no --no prefix
control to give default value to program.
In an [Interactive](https://nextjs.org/#interactive) approach, the user
can select a prompt; `Would you like to customize the default import
alias (@/*)? No / Yes.` If the user selects no, then the default alias
is applied with @/*.
### How?
Implementing a condition solve the problem for general purpose. If
arguments includes `--no-import-alias` then the importAlias section
automatically apply the default value.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Steven <steven@ceriously.com>
### What?
Adds a new line to the `next info` output:
```diff
Operating System:
Platform: linux
Arch: x64
Version: #18~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Feb 7 11:40:03 UTC 2
+ Available memory (MB): 31795
+ Available CPU cores: 16
Binaries:
Node: 18.18.2
npm: 9.8.1
Yarn: N/A
pnpm: 8.15.1
Relevant Packages:
next: 14.1.1-canary.61 // Latest available version is detected (14.1.1-canary.61).
eslint-config-next: 14.1.1-canary.61
react: 18.2.0
react-dom: 18.2.0
typescript: 5.2.2
Next.js Config:
output: N/A
```
### Why?
This can help in debugging
### How?
Using [`os.totalmem()`](https://nodejs.org/api/os.html#ostotalmem) and
[`os.cpus()`](https://nodejs.org/api/os.html#oscpus)
Closes NEXT-2529
[Slack
thread](https://vercel.slack.com/archives/C046HAU4H7F/p1708359702870269?thread_ts=1708355509.771049&cid=C046HAU4H7F)
### Why?
While developing https://github.com/vercel/next.js/pull/57656, using
`webpack`(which runs `bundle5.js`) gives me the following error:
```
Error: Cannot find module 'next/dist/build/webpack/plugins/terser-webpack-plugin'
Require stack:
- .../node_modules/next/dist/compiled/webpack/bundle5.js
```
### What?
The path to
[terser-webpack-plugin](https://github.com/vercel/next.js/blob/canary/packages/next/src/build/webpack/plugins/terser-webpack-plugin/src/index.ts)
seems to be modified, but the `taskfile.js` for building `bundle5.js`
hasn't been updated since https://github.com/vercel/next.js/pull/29168.
### How?
- Added `src` after the `terser-webpack-plugin` path in `taskfile.js`
- Run `pnpm ncc-compiled` (not sure if this is the right command to
run), built `bundle5.js` only.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### Why?
We currently use `page` and `pathname` in different places for file
system paths (manifests can be in a different folder to the js entry),
this PR makes more things just use `page` directly instead of going
through `pathname`.
This PR also adds an entry key (similar to the webpack version) uniquely
identifying all entry points (and assets).
Closes PACK-2432
### What?
All the manifest loading logic now lives in the
`TurbopackManifestLoader` class.
We have to pass way fewer arguments around to the functions now.
I've also cleaned up / restructured the arguments of the bigger
functions in `turbopack-utils.ts` and gave some functions better names.
Closes PACK-2520
### What?
An unactionable error is thrown when `headers()`, `cookies()` or other
Dynamic API functions are called outside the render/request context.
This PR clarifies what the user can do to fix the problem.
### Why?
The current error is hard to understand
> Error: Invariant: `cookies` expects to have requestAsyncStorage, none
available.
### How?
I am adding a dedicated error page and rephrasing the error message.
Closes NEXT-2509
This PR adds catch-all matching support to Turbopack. This allows you to
have catch-all parallel slots.
Closes NEXT-2038
Closes PACK-2518
Fixes#59502
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What?
`css-loader` seems to have a linting rule for invalid CSS Modules.
[My Turbopack PR](https://github.com/vercel/turbo/pull/7381) implements
the same rule for `swc_css` and `lightningcss`, and this PR is for
enabling related test suite and updating the jest snapshot.
### Why?
`css-loader` has a similar linting rule.
### How?
Closes PACK-2408
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
Previous implementation of `sendGAEvent` was pushing arguments to
`dataLayer` via rest parameter syntax, resulting in an actual array,
which GA doesn't seem to process correctly (resulting in the event not
showing up in GA reports). This PR refactors it to a vanilla JS function
passing data via the `arguments` array-like object, which is able to be
processed correctly and results in the event showing up as expected.
fixes [61703](https://github.com/vercel/next.js/issues/61703)
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
Closes PACK-2469
Trying to add some description to the one of the public interface.
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
It’s not possible to combine `export =` type definitions with ESM-style
exports. To export types for a module that uses `module.exports =`, one
needs to use a namespace.
Also `Options` is now imported from `@mdx-js/loader`. The imports need
to come from a direct dependency or peer dependency. Also
`@mdx-js/loader` is more accurate here, because the options are passed
into `@mdx-js/loader`.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### 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
This fills the last piece in the puzzle and it's based on #61001. In
#61001 we covered the case of nested Server Action definition in a non
"use server" file. And this PR extends that to a "use server" file so
exported values are automatically handled just like before, but any
other definitions including nested ones will be hoisted and marked
correctly now.
```ts
'use server'
let a, f
export async function action0(b, c, ...g) { // <- Handled like before.
return async function action1(d) { // <- Renamed, marked and hoisted.
'use server'
let f
console.log(...window, { window })
console.log(a, b, action2)
async function action2(e) { // <- Renamed, marked and hoisted.
'use server'
console.log(a, c, d, e, f, g)
}
return [
action2,
async function action3(e) { // <- Renamed, marked and hoisted.
'use server'
action2(e)
console.log(a, c, d, e)
},
]
}
}
```
Closes NEXT-2491
### 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
## What?
Noticed this file was being `require`ed but doesn't actually hold
anything relevant as the flag it adds was removed already.
Also found that in the next-core crate there were files that are no
longer needed as it uses Next.js directly now. That fixes a bug when
running with `NextMode::Build` as well, as it couldn't resolve some of
these unused files.
<!-- 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-2500
This ensures we don't normalize the `distDir` in the webpack config in
dev mode as it won't be moved to the right location like it is during
build.
Fixes: https://github.com/vercel/next.js/issues/61105
Closes NEXT-2495
### What
Disable swc transform optimizer for node_modules in browser layer of app
router bundles
Fixes#61858Fixes#60644Fixes#60920Fixes#61740
Closes NEXT-2418
### Why
In browser there could be not only one runtime, it could have both js
worker and browser. In js worker the `typeof window` is not as same as
in browser, so disabling the swc optimizer which will replace the code.
Leave the condition as it as.
### Why?
I really dislike the way `.chain` works right now, it shouldn't mutate
the `BrowserInterface`, this PR changes it so it's just a pure chain
without weird side effects.
One example with the current version (before this PR):
```
const el = browser.elementByCss('#version-2')
await el.text()
// throws
await el.text()
```
### Additional Changes
- removes selenium (which is completely unused)
- updates playwright
- makes the playwright tracing not error all the time
### What?
Probably not the right solution, next.js disables the `react-server`
import condition in there somehow I think
### Why?
Resend uses `@react-email/render` which uses `renderToString` from
`react-dom/server`.
Unfortunately importing `react-dom/server` with the `react-server`
import condition leads to a broken bundle (which seems like a bug in
react?).
Closes PACK-2243
Fixes#57936
### What
When a global not found page is rendered, and when the not-found page or
containing layout has a link with `prefetch: auto` back to the root
page, the router would update the URL but not correctly swap out the
not-found component with the page component.
### Why
With auto prefetching (which is the default when `prefetch` is left
unspecified on a link), the router will perform a partial prefetch on
dynamic pages. This means it'll fetch the flight data _without_ React
nodes and store it in the prefetch cache. On navigation, this is used to
determine where we already have cached React nodes and where we need to
trigger a lazy fetch to get new data. However, global not found pages
are peculiar in that they will always contain a data path like: `['', {
children: ['__PAGE__', {}] }]` since they are inserted at the root. This
means that if there's also a page component that corresponds with the
same path, the router will incorrectly think it already has cache node
data for it.
### How
During SSR when the `asNotFound` flag signals to the renderer that the
component we're rendering is matching the global not-found page, we
modify the segment key to be something unique so the data path won't
collide with a top-level page.
In
[fc01c8e](fc01c8e7f7)
I added handling only on the server to modify the segment key. This
still fixes the issue, but at the cost of triggering an MPA navigation
on the client because it's treated as a root layout change
In
[69d5687](69d5687765)
I added client handling to not treat this special segment key as a root
layout change, and to signal to the router it needs to refetch the data.
This ensures we don't do an MPA navigation.
Fixes#61956
Closes NEXT-2481
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
Turbopack uses `parse_as_prorgram`, and in case of empty file it returns
script instead of module so none of visitor runs for the rsc module.
This PR attempts to workaround, however need double clarification if
upstream swc behavior is desired.
Closes PACK-2460
### What?
This PR improves turbopack documentation, mostly collects existing
documents into a single place.
Also, adds a support to render mermaid diagram.
Closes PACK-2488
Moved app-dir path params parsing logic from `useParams` to `AppRouter`.
This allows for the use of `PathParamsContext` in the `useParams` hook
for both pages and app routers. In addition, this allows for memoization
of the layout tree which fixes undesired re-renders of the `useParams`
hook.
Fixes [#58788](https://github.com/vercel/next.js/issues/58788)
Closes NEXT-2434
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What
Fix the externals resolving for server rendering layer for app router.
For SSR requests, if it's next externals, we resolved and return early,
if we didn't resolve, keep going through the following externals
resolving
### Why
Previously on app router's SSR bundling layer, we didn't go through the
following requests when seeing an server external package, it will keep
bundling even it's in server components external packages.
A bug found in #61983
Closes NEXT-2473
`createActionProxy` isn't the accurate name here - the function doesn't
return anything new but only mark the value as registered. And also, it
might not be a proxy (which is implementation detail) and might not be
used for Server Actions only. `registerServerReference` is a better name
here.
There's no functionality change in this PR, only a few renames.
Closes NEXT-2490
### What
Merges the package into the internal overlay.
### Detailed Changes
* Move `@next/react-dev-overlay` into next package and rename the import
paths.
* Fix the `getErrorSource` symbol issue, use `Symbol.for()` instead of
`Symbol`
* Extra `getErrorSource` into single lib as it's being used in a lot of
places, this will keep the same bundle size
Closes PACK-2261
Closes NEXT-1977
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
In `v14.0.2-canary.1` users started noticing more memory errors
especially with many edge runtime configured pages. After investigation
it seems this can be related to the additional transpiling we configured
in https://github.com/vercel/next.js/pull/59569 and
https://github.com/vercel/next.js/pull/57784
To help alleviate this we are updating the default swc loader to have an
additional check to see if no special features such as `next/font`,
`next/dynamic`, or `use server/client` directives are present and then
no-oping in the loader to avoid additional overhead for a majority of
modules.
For monitoring regressions our `stats-app` has been updated with
repeated edge-ssr routes to hopefully help us keep an eye on memory or
cache size issues.
x-ref: NEXT-2430
x-ref: NEXT-2395
x-ref: NEXT-2299
x-ref: NEXT-2324
x-ref: NEXT-2373
Closes NEXT-2479
### What
This PR changes setup for the turbopack documentation.
Long story in short, we want to 2 types of documentation: one for high
level description (archtecture, etcs) and another for the api doc.
rustdoc / cargo doc unfortunately doesn't support to integrate both
easily.
PR adds mdbook setup to workaround those - instead of using rustdoc's
index as entrypoint, mdbook becomes an entrypoint to rustdoc. This
allows to host plain text document, and also able to access full rustdoc
pages.
preview: https://turbopack-rust-docs-b6qta4xdq.vercel.sh/
rustdoc:
https://turbopack-rust-docs-b6qta4xdq.vercel.sh/rustdoc/index.html
Closes PACK-2475
Closes PACK-2468
### What
When navigating back to a page that you had already loaded, it currently
results in a prefetch cache miss and will re-trigger any data
fetching/loading despite it being available.
### Why
When creating the initial router state, the prefetch cache is
initialized to an empty map.
### How
This uses the `initialTree` passed from the server to seed the cache for
that route with flight data.
Closes NEXT-2001
### What
Prefetches to pages within a shared layout would frequently cache miss
despite having the data available. This causes the "instant navigation"
behavior (with the 30s/5min TTL) to not be effective on these pages.
### Why
In #59861, `nextUrl` was added as a prefetch cache key prefix to ensure
multiple interception routes that correspond to the same URL wouldn't
clash in the prefetch cache. However this causes a problem in the case
where you're navigating between sub-pages. To illustrate the issue,
consider the case where you load `/foo`. This will populate the prefetch
cache with an entry of `{foo: <PrefetchCacheNode}`. Navigating to
`/foo/bar`, with a link that prefetches back to `/foo`, will now result
in a new cache node: `{foo: <PrefetchCacheNode>, /foo/bar%/foo:
<PrefetchCacheNode>}` (where `Next-URL` is `/foo/bar`). Now we have a
cache entry for the full data, as well as a cache entry for a partial
prefetch up to the nearest loading boundary. Now when we navigate back
to `/foo`, the router will see that it's missing data, and need to
lazy-fetch the data triggering the loading boundary.
This was especially noticeable in the case where you have a route group
with it's own loading.js file because it creates a level of hierarchy in
the React tree, and suspending on the data fetch would result in the
group's loading boundary to be triggered. In the non-route group
scenario, there's still a bug here but it would stall on the data fetch
rather than triggering a boundary.
### How
In #61794 we conditionally send `Next-URL` as part of the `Vary` header
if we detect it could be intercepted. We use this information when
creating the prefetch entry to prefix it, in case it corresponds with an
intercepted route.
Closes NEXT-2193
### What
When navigating to a page that uses a loading boundary + parallel route,
an empty white screen would be displayed rather than the loading state /
final state
### Why
With parallel routes, the RSC data is an array of data paths, each
corresponding with one of the parallel segments rendered on the page.
During the navigation event, when we iterate over this data, we call
`applyFlightData` with this data path & an empty cache node.
`applyFlightData` checks to see if the flight data contains cache nodes
("seed data"). If it doesn't, then that means it has no work to do, and
it bails out. Pre-PPR and in the case of having a `loading.js` file,
`walkTreeWithFlightRouterState` doesn't return any seed data, just
router state. This means that `applyFlightData` will not have any work
to do on the new cache node, and leaves it untouched.
Once `applyFlightData` is finished, but while still in the flight data
path loop, we reassign `currentCache` to the empty cache object we
created prior to `applyFlightData`. But since that cache node has
remained empty, the next iteration of the loop is going to be inspecting
a now empty cache, rather than the actual "current" cache. Now there's
no existing cache to copy into the new cache. The app now doesn't know
about any cache nodes.
### How
It doesn't seem like we should be re-assigning `currentCache` to the new
cache. In the context of a navigation, it seems more accurate to always
assume `currentCache` is the cache _now_, since it won't actually be
applied to the state until the action has finished (`mutable.cache` is
currently taking care of this).
Closes NEXT-2223
Fixes#61080
followup to: https://github.com/vercel/next.js/pull/60645
### Background
When prerendering the determination of whether a prerender is fully
static or partially static should not be directly related to whether
there is a postponed state or not. When rendering RSC it is possible to
postpone because a dynamic API was used but then on the client (SSR) the
postpone is never encountered. This can happen when a server component
is passed to a client component and the client component conditionally
renders the server component.
Today if this happens the entire output would be considered static when
in fact the flight data encoded into the page and used for bootstrapping
the client router contains dynamic holes. Today this is blocked by an
error that incorrectly assumes that this case means the user caught the
postpone in the client layer but as shown above this may not be the
case.
### Implementation
A more capable model is to think of the outcome of a prerender as having
3 possible states
1. Dynamic HTML: The HTML produces by the prerender has dynamic holes.
we save the static prelude but expect to resume the render later to
complete the HTML. This means we will resume the RSC part of the render
as well
2. Dynamic Data: The HTML is completely static but the RSC data encoded
into the page is dynamic. We don't want to resume the render but we do
need to produce new inlined RSC data during a Request.
3. Static: The HTML is completely static and so is the RSC data encoded
into the page. We save the entire HTML output and there will be no
dynamic continuation when this route is visited.
Really 1 & 3 are the same as today (Partially static & Fully Static
respectively) but case 2 which today errors in a confusing way is now
supported.
In addition implementing the Dynamic Data case the old warning about
catching postpones is removed. The reason we don't want this is that
catching postpones is potentially a valid way to do optimistic UI. We
probably want a first-party API for it at some point (and maybe we'll
add the warning back in once we do) but imagine you do something dynamic
like look up a user but during prerender you want to render as if the
user is logged out. you could call `getUser()` in a try catch and render
fallback UI if it throws. In this case we'd detect a dynamic API was
used but we wouldn't have a corresponding postpone state which would put
us in the Dynamic Data case (2).
Another item to note is that we can produce a fully static result even
if there is a postponed state because users may call postpone themselves
even if they are not calling dynamic APIs like headers or cookies. When
this happens we don't want to statically capture a page with postponed
boundaries in it. Instead we immediately resume the render and abort it
with a postponed abort signal. This will cause the boundaries to
immediately enter client render mode which should speed up recovery on
the client.
#### Technical Note
Another note about the implementation is that you'll see that regardless
of which case we are in, if there is a postponed state but we consider
the page to be Dynamic Data meaning we want to serialize all the HTML
and NOT do a resume in the dynamic continuation then we immediately
resume the render with and already aborted AbortSignal. The purpose here
is to mark any boundaries which have dynamic holes as being
client-rendered.
As a general rule if the render produces a postponed state we must do
one of the following
1. save the postponed state and ensure there is a dynamic continuation
that calls resume
2. immediately resume the render and save the concatenated output and
ensure the dynamic continuation does NOT call resume.
or said another way, every postponed state must be resumed (even if it
didn't come from Next's dynamic APIs)
#### Perf considerations
This PR modifies a few key areas to improve perf.
Reduces quantity of *Stream instances where possible as these add
significant overhead
Reduces extra closures to lower allocations and keep functions in
monomorphic form where possible
Closes NEXT-2164
### What
We'd like to deploy generated rustdocs from turbopack & related packages
(next-swc), setting up a CI workflow to automate those.
Since we need next.js side packages to build docs, this CI sets up
things in this repo.
Closes PACK-2375.
### What?
Bump up turbopack to latest. This is to cut off turbopack **before**
including filewatcher changes, so we can easily bisect & revert if
watcher have regressions.
Previously, this error was confusing because it made it sound like the
`sizes` prop was missing. This was because the default value of `sizes`
is `100vw` so the previous code couldn't tell the different between
implicit vs explicit `100vw`.
This PR changes the code to read the input value from the `sizes` prop
and prints a better warning.
Fixes NEXT-2441
There was a bug where if the root hydrates and then an update happens
the intitial server data response can be replaced by one that is
completely empty and will never resolve. This can lead to a frozen
hydration that blocks interactivity. This udpate makes it so it is
impossible for the initial data response to ever be created more than
once.
Making a regression test is tricky because this relies on subtle timing
of hydration, updates, and when the inline chunks arrive in the stream.
The original implementation is just not safe in that it violates the
rules of react and the new one is self-evidently unable to produce a
similar situation so as long as our existing test suite passes that must
be sufficient absent a good alternative to making a specific regression
test
Closes NEXT-2420
In #61794, the routes manifest is used to find the interception route rewrites in `next-server` and computed on the fly in `next-dev-server` based on `appPaths`.
The edge runtime doesn't have access to the routes manifest nor a full list of app paths. This writes an entry for the edge runtime to make the interception routes readable, and adds plumbing to return them in the `getInterceptionRouteRewrites` handling in `web-server`. This is what we use to signal to the server whether to return ‘Next-URL’ in the Vary for RSC requests.
This piggybacks on the existing interception routes test but adds an edge runtime case.
Closes NEXT-2304
To ensure that we properly cache data for routes that change based on `Next-URL` (which is used for route interception), this adjusts how we set the `Vary` header to conditionally include `Next-URL`.
The `Next-URL` request header only impacts the response for routes that are intercepted. When we detect that path we're handling could be intercepted, we add `Next-URL` to the vary. This signals in #61235 to prefix these cache entries with `nextUrl` if the response might vary based on it.
Closes NEXT-2398
### Fixing a bug
### What?
Fix remotePatterns when all paths and/or domains are allowed.
### Why?
micromatch creates a very strange regex for all paths -
`/^(?:(?!\.)(?:(?:(?!(?:^|[\\/])\.).)*?)[\\/]?)$/`. That is, paths
cannot start with a dot or contain a slash followed by a dot.
Interestingly, here are some valid paths:
- /a/a.a/6a00d8341c4fbe53ef02c8d3a82122200d-600wi
- ////a/a.a/6a00d8341c4fbe53ef02c8d3a82122200d-600wi
- ///:?%;№%/a/a.a/6a00d8341c4fbe53ef02c8d3a82122200d-600wi.\/
- /:./6a00d8341c4fbe53ef02c8d3a82122200d-600wi.\/
And here are some invalid ones:
- /.a/6a00d8341c4fbe53ef02c8d3a82122200d-600wi
- /a/.a/6a00d8341c4fbe53ef02c8d3a82122200d-600wi
- ./a/6a00d8341c4fbe53ef02c8d3a82122200d-600wi
I don't think this check makes any sense.
### How?
If the user allows all (`**`) - it means any path or domain will be
considered valid.
- Fixes#60483
- Fixes#58139
- Fixes#46903
---------
Co-authored-by: Steven <steven@ceriously.com>
### Why
The `process/browser` lib was imported and being transformed, but
`process.browser = true` turns to `true = true` that causes the
compilation error, we need to exclude them from certain compilation
layers
### What
- Fixes https://github.com/vercel/next.js/issues/61116
Closes NEXT-2410
Closes NEXT-2328
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
Unclear when this can happen currently (hence missing a test), but this adds a safeguard to `applyUrlFromHistoryPushReplace` to ensure that we don't potentially call `ACTION_RESTORE` with data that might be missing from `window.history.state`.
This is consistent with other spots where we're reading this internal flag from state.
The function that calls `applyUrlFromHistoryPushReplace` first calls `copyNextJsInternalHistoryState` to copy over `__PRIVATE_NEXTJS_INTERNALS_TREE` into the data argument of `pushState`/`replaceState`. But technically it does so with the possibility that `__PRIVATE_NEXTJS_INTERNALS_TREE` is undefined. Since that's the case, this is more typesafe.
Closes NEXT-2406
### What
Skipping module build error and module not found error in
`onUnhandledError` handler from pages router dev overlay, to avoid the
build error being caught twice by error overlay in both unhandled error
and build error type. The unhandled error is slightly eariler than build
error, which causes the flash. We skipped it to avoid display same
duplicated errors.
### Why
This change fixes a flashing UX on error overlay when build error
occurred, it will go from a white background with red text to a source
panel with actual code where triggered build error, such as synatx
error. I recodered two videos to show them properly. Since it happens
too fast, hard to address them with test, more like fixing a minor
frustration in the UI.
### After
https://github.com/vercel/next.js/assets/4800338/59dcde0f-3ac7-419f-ba5c-c28c9d5a7205
### Before
https://github.com/vercel/next.js/assets/4800338/e64e8855-2c5f-43a5-948c-8137cad538a1
Closes NEXT-2403
Closes NEXT-2145
This implements falling back to try multiple locations loading chunks
for sourcemap tracing.
Unfortunately, when RSC replays server errors on the client, it does not
carry over the [0] symbol used to annotate server frames. Instead,
errors are recreated by React and only include the message and stack.
This allows more tests to pass, as we are able to correctly trace stack
frames by loading the appropriate server chunk.
Closes PACK-2442
### What
This PR injects a build-time error for the turbopack if
`client|server-only` is imported in incorrect context. The basic idea is
using resolve plugin, so in resolve time if matching context (which
alises erroneous import), raise a build time error.
Unfortunately this won't fix all of the tests in `invalid-imports`, due
to
1. resolveplugin does not have way to trace import from transformed, so
not able to detect `styled-jsx` from using `<styled..` tags
2. webpack (in our implementation) and turbopack's resolveplugin have
different order of transform / module trace chain, so enabling resolve
plugin in some context raises build error instead of runtime error in
rsc-build-error.
Closes PACK-2397
Fixes: #47978
When an error occurs in getInitialProps, the error page's
getInitialProps is run server-side and returned in `__NEXT_DATA__`.
Following, there's no need to re-run `getInitialProps` client-side on
the hydrate pass.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
In preparation for the refactor of cache utils in subsequent PRs, this PR moves the one-off prefetch cache utils into a shared `prefetch-cache-utils` file, and also relocates the `buildCustomRoute` util into an isolated lib so that it can be imported into base-server (in a future PR).
This PR does not make any changes to these functions.
Closes NEXT-2394
### What
Exclude precompiled react packages from browser layer loaders coverage.
### Why
Since we're transpiling all the browser layer code now after #59569,
then SWC will also compile react. But when it compiles
`react.production.min.js` it gives me with the code and ESM helper
inserted
```js
import { _ as _type_of } from "@swc/helpers/_/_type_of"; // This is not correct
var l = Symbol.for("react.element"), n = Symbol.for("react.portal"), p = Symbol.for("react.fragment"), q = Sym
bol.for("react.strict_mode"), r = Symbol.for("react.profiler"), t = Symbol.for("react.provider"), u = Symbol.f
```
This makes bundler think it's a ESM package but actually it's CJS, which
converts the module into `{ default: .., __esModule }` instead of the
original react module.
When you're using `React.useEffect` or other API through namespace
import (`import * as React from 'react'`), this will break the module
exports check in bundling as the property doesn't directly attached to
the module now. This PR disabled the transform for precompiled react
packages now and will see the deeper issue in next-swc side later.
Fixes#60890Fixes#61185
Closes NEXT-2362
### What?
Fix the user-facing `MiddlewareConfig` interface.
~While in the codebase, I also made the incoming config object type a
bit more strict by converting from `any` to `unknown`.~ Reverted, as we
do a config assertion already in a [different
place](https://github.com/vercel/next.js/blob/canary/packages/next-swc/crates/next-custom-transforms/src/transforms/page_config.rs/#L171-L180).
### Why?
The interface we previously exposed was the one we used internally,
_after_ we did some parsing on the config object, which is different
from what the user is expected to pass.
### How?
I separated the internal type to its own `MiddlewareConfigParsed`
interface.
Closes NEXT-2375
Fixes#61705
Ref: #61576
### What?
depends on https://github.com/facebook/react/pull/28108
* fixes CSS Ordering issues due to CSS duplication in production mode
* The issues still happen in dev mode
* Highlights broken CSS Ordering for more dev cases, e. g. CSS in client
components
Closes PACK-2300
### What?
fixes unexpected use client build warning in some applications.
We've consolidated all the ecmaplugins into custom rules. It behaves
different for the ecma inputs, while plugin runs any ecmascript inputs
rules only runs with matching target. The culprit module in question was
published as `.mjs`, so the necessary transform didn't ran.
Closes PACK-2419
In #61649 the paragraph `"This function allows you to redirect the user
to another URL. It can be used in..."` describing `notFound` was copied
as is from the `redirect` jsDoc
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What
This adds support for navigation signals like `notFound()` and
`redirect(url)` when Partial Prerendering has been enabled.
### Why
Navigation API's like `notFound()` and `redirect(url)` throw errors in
order to interrupt the rendering of components. When a page both invokes
API's that cause the render to be marked as dynamic (like
`unstable_noStore()`) and also a navigation API, these errors may race
to the end. In the case where the navigation error does not beat out the
error emitted by dynamic API's will still trigger the detection warning
that's present to warn you about situations where you may have
accidentally caught the error.
### How
This resolves this issue by explicitly checking for navigation signals
(errors) thrown during the render, and not displaying the "caught
dynamic API" error and console warning.
Closes NEXT-2037
## History
Previously, we added support for `squoosh` because it was a wasm
implementation that "just worked" on all platforms when running `next
dev` for the first time. However, it was slow so we always recommended
manually installing `sharp` for production use cases running `next
build` and `next start`.
Now that [`sharp` supports
webassembly](https://sharp.pixelplumbing.com/install#webassembly), we no
longer need to maintain `squoosh`, so it can be removed. We also don't
need to make the user install sharp manually because it can be installed
under `optionalDependencies`. I left it optional in case there was some
platform that still needed to manually install the wasm variant with
`npm install --cpu=wasm32 sharp` such as codesandbox/stackblitz (I don't
believe sharp has any fallback built in yet).
Since we can guarantee `sharp`, we can also remove `get-orientation` dep
and upgrade `image-size` dep.
I also moved an [existing `sharp`
test](https://github.com/vercel/next.js/pull/56674) into its own fixture
since it was unrelated to image optimization.
## Related Issues
- Fixes https://github.com/vercel/next.js/issues/41417
- Closes https://github.com/vercel/next.js/pull/54670
- Related https://github.com/vercel/next.js/issues/54708
- Related https://github.com/vercel/next.js/issues/44804
- Related https://github.com/vercel/next.js/issues/48820
- parsed stack traces (and error stack locations in js) have 1-based
lines and 1-based columns
- source map tokens have 0-based lines and 0-based columns
- babel code frames use 1-based lines and 0-based columns
This was not always respected. This preserves the 1-based lines and
columns in anything called a stack frame, 0-based lines and columns for
source map apis, and converts to babel’s format as needed.
Closes PACK-2341
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
<!-- 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
### How?
Closes NEXT-
Fixes #
-->
### What?
This PR introduces a ground work to generate wasm bindings package from
our napi bindings. This doesn't actually replace anything yet, however
aim to establish our napi bindings package can be built against wasm32
target.
### Why?
We currently have two bindings package to generate native / wasm target
support, one for napi and one other for wasm. Recently napi-rs started
to support to generate bindings for the wasm directly - which means we
can get rid of the wasm-pack based bindings code entirely and maintain a
single bindings code only.
This'll makes our `next-swc` simpler as well, since the invocation to
the bindings now becomes identical we don't have to additional wasm
specific logics to invoke functions (i.e transform, transformsync..).
Also napi generates wasi-supported wasm bindings, provides few more
features to the current wasm bindings.
#### Good
- Async napi binding fn works transparently (`transform`, `minify`...)
- (Experimental) thread supports depends on node.js runtime
- Wasi support: i.e it can even read filesystem directly!
#### Things to consider
- node.js's wasi support is experimental yet
- napi-rs's wasm support is in beta yet, specifically `packaging`
generated wasm output.
Due to `things to consider` reasons, this PR does not replace existing
wasm target yet. We should be able to plan out things later.
**What happens to the turbopack api in napi bindings?**
Simply put, this **does not support turbopack in wasm**. Build works by
disabling turbopack (more notably, underlying dependency doesn't support
wasm) features. It is something to explore separately.
Closes PACK-2367
There is a branch at https://github.com/vercel/next.js/pull/61586 shows
quick demo for importing, running sync / async / read external files.
### What?
This PR wraps up supporting rsc transforms (mostly for the assertion) in
Turbopack. PR contains a few changes to support it, including:
- adjust / expand transform rules for the corresponding contexts
- fix file name / node_modules check
- extract visitors for the assertion / transforms
This change enables most of the rsc-build* tests and some more other
tests. The only failing tests in the rsc-build-errors is due to
Turbopack not triggering hmr with empty file.
Closes PACK-2303
### What & Why
We have a modularize imports config for `next/server` before, which will
transform the `next/server` imports to directly import from the actual
file, for instance: `import { NextRequest } from 'next/server'` will
become `import { NextRequest } from
'next/dist/server/web/exports/next-request'`, where the NextRequest is
exported as default export. This is fine in most case until you're using
a ESM pkg, then it will be resolved as `{ default: NextRequest }`
according to the spec. Since it's a ESM import to a CJS module in
`next/dist`.
Since we already have the ESM alias introduced in #59852 , this can
handle the case more properly.
### How
Remove the modularize imports config for `next/server`, use the ESM api
alias instead.
Migrate the cjs optimizer tests from middleware to a separate endpoint
`/cjs/server`. As now ESM imports for next/server are not going to get
tree-shaken in dev, but since we don't have image response there it's
still fine.
Closes NEXT-2376
Closes NEXT-2374
### What
When navigating to a page with dynamic params using a certain casing,
and then following a link to another page using _different_ casing for
the same param, the router would get stuck in an infinite suspense
cycle.
### Why
On the client we normalize cache keys by lowercasing the values for
dynamic segments. However the RSC data for each segment wouldn't have
this same casing logic applied. This is causing the router to not
recognize that there is already RSC data available for that segment,
resulting in an infinite suspense cycle.
### How
The `toLowerCase()` logic shouldn't be needed here. Technically we could
leave this in place and update `matchSegment` to also apply the
lowercase logic, but currently there are too many utility functions that
parse segments to comfortably make that change. I confirmed that the bug
related to why we lowercased these router cache keys is no longer
present after making this change.
Fixes#61722
Closes NEXT-2377
### What?
Let the developer check the instance of `ReadonlyURLSearchParams` to
match against `URLSearchParams`
### Why?
`useSearchParams()`'s return type is `ReadonlyURLSearchParams` which
implements all the methods of `URLSearchParams`, therefore its type
should be extended from `URLSearchParams` as well. Deprecated methods
are also implemented to throw an error, so no runtime behavior is being
changed
### How?
Mark the unavailable methods as `@deprecated` which will visually mark
them in IDEs:
This is similar how `ReadonlyHeaders` extends `Headers`, added in:
#49075
[Slack
thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1706628877916779)
Closes NEXT-2305
### What
Client-side transitioning to a page that triggered a loading boundary
with async metadata would cause the transition to stall, potentially
getting stuck in a refetch loop.
### Why
In layout-router, we trigger a "lazy fetch" when we encounter a segment
that we don't have cache nodes for. This calls out to the server and
suspends until the data fetch is resolved, and applied to the router
tree. However after suspending but before updating the client router, we
set `childNode.lazyData` to null. When we unsuspend from the server
patch action, `childNode.rsc` might still be missing and clearing
`lazyData` means we've blown away the reference to the fetch we already
had pending, triggering a refetch loop.
### How
This removes the logic that mutates the cache node in render, as this is
not concurrent safe, and doesn't appear to be needed for anything.
Fixes#61117
Closes NEXT-2361
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
### What
#### Core
This PR respect the error's digest when recieves new error occurred from
server side, and it will be logged into client on production with the
same `digest` property.
If we discover the original RSC error in SSR error handler, retrieve the
original error
#### Tests
* Move the errors related tests from `test/e2e/app-dir/app` to a
separate test suite `test/e2e/app-dir/errors`
* Add a new test case for logging the original RSC error
* Add a new test case for logging the original Server Action error
### Why
This will help associate the `digest` property of the errors logged from
client with the actual generated server errors. Previously they're
different as we might re-compute the digest proper in handler that react
server renderer thinks it's a new error, which causes we have 2
different errors logged on server side, and 1 logged on client side. The
one on client side can associate to the server errors but it's from
react renderer which is not the original error.
Closes NEXT-2094
Fixes#60684
### What?
I forgot to check the `preload` option when implementing it and just
looked at the `subsets`.
This also fixes duplicate preload tags by adding them to a set in the
default `_document.tsx`
Closes PACK-2392
This PR fixes `.eslintrc.json` not being created after the user runs
`next lint` and selects an option of `Strict` or `Base`.
The reason is that the lint check was looking for `pages` and
`src/pages` only. Added `app` and `src/app` to be checked also.
Fixes: #55094Fixes: #55102
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
Fixes `setAssetPrefix` when running on a custom server using next()
function
### Why?
Looks like when we run next custom server, there are 2 instances created
to handle this case
* main server in `/server/next.ts`
* and Render server `./server/lib/render-server.ts`
The issue mainly happens when calling `setAssetPrefix` it will update
only the main server and not render server
``` javascript
const next = require('next')
const app = next({ });
app.setAssetPrefix('my-fancy-cdn/static');
app.render(); // render server is used instead of the main server
```
### How?
when calling `setAssetPrefix` on the main server also update the render
server with the same information.
Fixes: #59940Fixes: #51223Fixes: #61383
### Related Resources
#53523#49805c9c6ff6d77/docs/03-pages/01-building-your-application/06-configuring/10-custom-server.mdx
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What
This PR attempts to adjust import map to `server-only` / `client-only`
close to the existing webpack configs, makes to pass more tests.
Closes PACK-2396
### What?
This PR adds JSDoc comments to the most common public APIs to improve
the DX in IDEs like VSCode.
### Why?
Currently, we provide no information on some of the most used APIs in
IDEs, which makes it harder than it needs to be to look up the extra
information.
<details>
<summary><b>Before:</b></summary>
<img
src="https://github.com/vercel/next.js/assets/18369201/8b6092e8-8f9b-49da-a3df-b07a59982069"
width="640"/>
</details>
<details>
<summary><b>After:</b></summary>
<img
src="https://github.com/vercel/next.js/assets/18369201/30216f76-414a-43b0-9aa6-2fdd742ab3fe"
width="640"/>
</details>
### How?
Using JSDoc comments, I added a basic description to most public APIs
that link back to the current docs for more details. The description is
kept minimal to avoid out-of-sync documentation.
Note: In the future, the flow could be reversed here, and our API
Reference docs could actually be generated from a single source of
truth, the source code itself. However, this will require more work by
re-organizing our public API submodules in a single directory, (related
#61525), so the API docs are easy to maintain even without a deeper
knowledge of the codebase.
Note: These comments should also be extended to
methods/properties/arguments in these public APIs in the future.
Closes NEXT-2357
[Slack
thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1706735292633029)
### What?
Removing `autoprefixer` from the default Tailwind CSS templates. (It can
be installed afterward)
### Why?
After some investigation by @timneutkens, `autoprefixer` seems to
introduce some compilation overhead
### How?
Removing `autoprefixer` from the auto-installed dependency list, it
would be up to the developer to install this plugin if they need it.
[Slack
thread](https://vercel.slack.com/archives/C04DUD7EB1B/p1695288906722539)
See here for additional context
https://github.com/vercel/edge-runtime/pull/795 but TLDR is due to a bug
in the `npmcli` we aren't able to publish Next.js releases after this
package was upgraded.
We can re-land the upgrade after that PR is landed/published.
Reverts vercel/next.js#61030
Closes NEXT-2367
### What?
Expose the `MiddlewareConfig` interface.
### Why?
You can now `import type { MiddlewareConfig } from "next/server"` to
type the `config` object in your `middleware.ts` file.
Now you an type the entire file for example like so:
```ts
// middleware.ts
import type { NextMiddleware, MiddlewareConfig } from "next/server"
export const middleware: NextMiddleware = async (req) => {
//...
}
export const config: MiddlewareConfig = {
//...
}
```
### How?
Re-exported the interface from its current location via
`server/web/types`, to colocate it with `NextMidldeware`.
I wonder if we could somehow type this file automatically, but it might
be dependent on https://github.com/microsoft/TypeScript/issues/38511
Closes NEXT-2308
[Slack
thread](https://vercel.slack.com/archives/C03S9JCH2Q5/p1706287433026409?thread_ts=1706058855.423019&cid=C03S9JCH2Q5),
[Slack
thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1706659724141899)
## Improving Documentation
### The following changes have been made to the official repository's
**Readme.md**:
- Shortened link text across the readme.
- Added additional descriptions for more details.
- Added bold text to highlight emphasis on important topics
- Changed heading sizes to indicate first headings (h1) for each section
instead of second headings (h2) which was previously being used
- Merged _'Who is using Next.js?'_ section with _'Getting Started'_
section for a more professional, cleaner look.
### The following changes have been made to the repository's
**Contribution docs**:
- Fixed two typos in the docs
---------
Co-authored-by: Sam Ko <sam@vercel.com>
Co-authored-by: Delba de Oliveira <32464864+delbaoliveira@users.noreply.github.com>
fixes#61390
### What?
Added encodeURIComponent to encode revalidateTag value beforing
appending it to the url.
### Why?
If a tag contains special characters the tag wont be revalidated because
the special characters arent encoded.
By encoding the tag any special characters can be used.
Check out issue #61390 for further explanation
I believe this is the reason why users report the revalidateTag as
unreliable. They might be using special characters in their tags to make
sure they are unique, but when deployed to vercel and the fetch cache is
used revalidateTag fail to revalidate them.
### How?
By encoding revalidateTag with encodeURIcomponent the tag can contain
special characters.
Closes NEXT-
Fixes#61390
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
Adds another `ImportMappingReplacement` for the font file in order to
add markers to the filename.
The markers are used to generate the `next-font-manifest.json` (and also
in next.js code).
Closes PACK-2352
### What
When attaching a rejection listener to a server action promise, in the case of network errors, the rejection handler would be skipped and it'd throw an error that crashes the application.
### Why
When we refactored these reducers to no longer suspend, it caused the rejection handling logic we have to no longer make sense. In this case we're working with a native promise that won't have a `status` property, so we'd re-throw the error and not call `reject`.
### How
This removes the special status handling logic and makes the rejection handler always call `reject` with the error. This will either be handled by user code or let the error bubble to an error boundary.
I also cleaned up some mutable code that is no longer needed now that these reducers aren't replayed.
Closes NEXT-1715
Closes NEXT-2323
Fixes#58638
This PR consolidates how we inject specific, custom ecma transforms for
the each context.
Previously we had 2 different way to apply custom transforms via
ecmatransform plugin / custom rules, but it could create some conflict
in order as well as can be confusing between how it gets created. PR
uses new moduleruleeffect instead, consolidates all of the references
into single way.
Closes PACK-2342
## What?
Fixes the `should update server components pages when env files is
changed (edge)` tests. In order for changes to the environment to apply
to edge-runtime routes we need to call `clearModuleContext`, currently
that only supports a single path being provided, but in Turobpack the
compilation is much more granular than webpack, in case of webpack we
loop through all items coming out of the compilation and invalidate them
regardless, which is not needed for Turbopack. Instead, when an
entrypoint (route) is recompiled it'll automatically only invalidate
that part. For `.env` changes that don't affect compilation, which is
what the test checks, this wouldn't be sufficient as there is no
compilation difference between changing those env vars. In the case that
you change `.env` / tsconfig/jsconfig we have to clear all module
contexts, which is what this PR implements.
<!-- 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-2337
### What?
We need the manifest to pass a bunch of preloading tests.
Currently, this is just a dumb implementation that preloads all fonts
and always sets size-adjust to true.
Google fonts are also still requested from Google directly it seems and
therefore never preloaded.
## What?
Whenever `.env` related files or tsconfig/jsconfig changes there's a
call to `invalidate()`, as far as I found the only call to
`invalidate()` even, which wasn't implemented for Turbopack yet. For
`NEXT_PUBLIC_` changes normal Turbopack HMR will kick in already but
this test was checking env vars that do not affect the compiled output,
so Turbopack would not trigger a HMR as no inputs changed. Similarly
webpack doesn't either and it implements this call in a similar way.
For edge runtime there's a different bug where changes are not
propagated even when you refresh, so while this change does fix another
bug for edge runtime it doesn't solve that underlying issue where the
values don't update to begin with. I'll investigate that next.
<!-- 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 #
-->
Follow up for #61463
Basically the fix in #61463 was not correct. I added a log to see which
react is resolved in `dynmiac-rendering` module, and the got this:
The module with incorrect react version is from
`next.js/packages/next/dist/compiled/next-server/app-route.runtime.prod.js`
which resolves `react` as `./dist/compiled/react/index.js` even
experimental react should pop in here.
Then I found the app-route runtime doesn't have check for the react exp
env, then I added there to make it aligned with app-page runtime
Closes NEXT-2327
Closes NEXT-2294
### What
The `arg` in the worker callback is alwasy `any`, when we access the
page path the argument could be in different form as the arg types are
different.
This PR align the argument type to object for `isPageStatic`,
`getDefinedNamedExports`, `hasCustomGetInitialProps` methods in static
worker. So they can share the similar shape of type of argument when
accessing `page` path. This will avoid the case that logged `page` in
the warning is `undefined`
Import the helpers from utils instead of workers as the worker itself
don't need to contain other exports that is not used for static worker.
### Why
This PR align the callback type of callback argument type of static
worker, so that we could get the actual page path value in a type-safe
way. We have 4 methods for static worker, `exportPage`, `isPageStatic`,
`getDefinedNamedExports`, `hasCustomGetInitialProps`, which the rest of
3 methods share the same format of warnings but their argument are
different. It's easily ended up with wrong argument type, and log with a
bad page path in the warning.
Closes NEXT-2289
### What?
This adds a method to optionally detect disk, network, and env access
access during a build and write this to a file.
### Why?
This will be consumed by Turborepo to determine **if** a build can be
cached, and if so, **how** it should be cached.
### How?
This implements a proxy that can be selectively applied to functions to
watch their access to disk, network, and env. For Turborepo, we only
care about what can alter the build output, to achieve this, we trace
the config load, and the static page generation.
Closes
https://linear.app/vercel/issue/TURBO-1904/support-build-access-tracing-in-nextjs
Performance Testing:
Repo -
https://github.com/tknickman/nextjs-turborepo-build-trace-performance-testing
```
- - - - - - - - - - - - - - - - - Performance - - - - - - - - - - - - - - - - -
pages-single-app:
44629.53301 ms (+/- 6313.82757 ms) from 5 iterations (223318.53692 ms total)
local-pages-single-app-with-trace:
45684.00503 ms (+/- 6570.85083 ms) from 5 iterations (228585.01729 ms total)
local-pages-single-app-without-trace:
45938.76231 ms (+/- 6816.13022 ms) from 5 iterations (229830.15925 ms total)
approuter-single-app:
49517.23156 ms (+/- 7820.20687 ms) from 5 iterations (247725.16713 ms total)
local-approuter-single-app-with-trace:
50019.98247 ms (+/- 9443.82537 ms) from 5 iterations (250224.62496 ms total)
local-approuter-single-app-without-trace:
50124.07092 ms (+/- 9656.22047 ms) from 5 iterations (250726.35688 ms total)
local-large-pages-single-app-without-trace:
51582.92992 ms (+/- 12179.09895 ms) from 5 iterations (258469.36942 ms total)
local-large-pages-single-app-with-trace:
51740.25813 ms (+/- 12601.02878 ms) from 5 iterations (259329.50946 ms total)
local-xlarge-pages-single-app-with-trace:
234111.66735 ms (+/- 74629.30509 ms) from 5 iterations (1191018.63608 ms total)
local-xlarge-pages-single-app-without-trace:
239621.11837 ms (+/- 84629.16374 ms) from 5 iterations (1218078.41921 ms total)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
```
<details>
<summary>Test case keys</summary>
* `local-xlarge-pages-single-app-without-trace`: this branch, built and
linked to a local project with 5000 SSG pages and trace **disabled**
* `local-xlarge-pages-single-app-with-trace`: this branch, built and
linked to a local project with 5000 SSG pages and trace **enabled**
* `local-large-pages-single-app-with-trace`: this branch, built and
linked to a local project with 100 SSG pages and trace **enabled**
* `local-large-pages-single-app-without-trace`: this branch, built and
linked to a local project with 100 SSG pages and trace **disabled**
* `local-approuter-single-app-without-trace`: this branch, built and
linked to a local default approuter starter and trace **disabled**
* `local-approuter-single-app-with-trace`: this branch, built and linked
to a local default approuter starter and trace **enabled**
* `local-pages-single-app-with-trace`: this branch, built and linked to
a local default pages starter and trace **enabled**
* `local-pages-single-app-without-trace`: this branch, built and linked
to a local default pages starter and trace **disabled**
* `approuter-single-app`: next@latest running on the default approuter
starter
* `pages-single-app`: next@latest running on the default pages starter
</details>
TODO:
- [ ] Telemetry events
This ensures we don't do un-necessary IPC calls during image optimizing
and leverage the internal request handler for fetching internal static
images/resources.
x-ref: https://github.com/vercel/next.js/issues/58248
Closes NEXT-2318
### What?
avoid sending issues turbopack messages to browser
### Why?
they trigger fake HMR events and are not used on client side anyway
Closes PACK-2338
### What
When using a default slot that re-exports another page, the CSS entries
(and presumably other client reference modules, like JS entries) that
correspond with the re-exported page won't be loaded, resulting in CSS
styles not being applied.
### Why
`next-app-loader` constructs the path to the default segment but special
cases the `children` slot (which is used as the page), to mark the
segment as an empty string. This is so that the parallel default file
can be loaded. However the way that `defaultPath` is constructed, it
assumes that `actualSegment` won't be an empty string, and constructs an
invalid path like so:
`app/example//default.tsx`
When we go to look up the JS/CSS entries from the client reference
manifest, the key will be incorrect and so it won't find the files for
it, resulting in this bug.
### How
This moves the `/` delimiting to be part of the creation of the
`actualSegment` variable so that we only append it when we know we
aren't setting it to be an empty string.
Fixes#52245Fixes#49871
Closes NEXT-2309
Closes NEXT-2310
### What?
On windows the .git/* files are read only, when the CNA "import path" script attempts to open one of the .git/* files
### Why?
attempting to open any of the .git/* files results in an error thrown by CNA and CNA exists, hence not finishing the setup of a new project
### How?
My suggested fix uses the fast-glob ignore option to exclude the .git folder, I also moved the the ts(js)config.json exclusion into the ignore (was an "if" before)
- Fixes#61411
- Discussion https://github.com/vercel/next.js/discussions/61261
When using `next/dynamic` in server components to load a client
component with named export, we shouldn't dot into the prop name since
client component reference as it's already a valid react component type.
It would work with `default` prop but not other named exports.
Let's say `mod` is a dynamic imported module
```
mod.Button.default
```
will become the client reference key
```
mod#Button#default
```
Which means in module `mod`, get `Button` export, then `default`
property of it, which is wrong but it's a valid key in the client
reference roxy.
This PR checks if they're client module, then return itself as dynamic
imported component type for `next/dynamic` if it is one.
Fixes#61046
Closes NEXT-2229
### What?
Avoid a dependency from the emit operation to the `get_and_write`
lookup.
### Why?
This makes HMR much faster since the `get_internal` method is pretty
slow.
Closes PACK-2337
### What
Catch-all parallel slots were being incorrectly matched to the root of their segment. For example, `@foo/[...catchAll]/page` as a parallel route on `/page.tsx` should not match on `/`, but it should match on `/foo`, `/bar`, ...etc
### Why
The catch-all route normalization logic doesn't treat optional catch-all routes differently from catch-all routes. The assumption was if any catch-all route was found, that it should match the path that shared its prefix.
### How
This updates the normalization logic to handle optional-catchall as it was in the original implementation. For regular catch-all, we ensure that the catch-all base path (for `/[...slug]` that'd be `/`) isn't identical to the path we'd match it to.
Fixes#60613
Closes NEXT-2243
Refining the message that uses "use with caution" instead of "use at
your own risk" as some experimental features was functionally stable but
we can't bring them as default for now and need to test as experiments
Closes NEXT-2286
### What
Given user infomation when the dynamic errors are thrown, e.g. bad
`cookies` or `headers` usages. Now users can tell through the error
information to see which pathname is broken, and trace down the usage.
#### before
```
Page couldn't be rendered statically because ...
This page needs to bail out of prerendering at this point because ...
```
#### after
```
Route /cookies couldn't be rendered statically because ...
Route /server needs to bail out of prerendering at this point because ...
```
### Why
When you have multi pages in your app, such as 100+, and many page might
uses these. This is hard to trace down where exactly the error is from
Closes NEXT-2283
Cloese NEXT-2265
- Updates `tailwindcss` package
- Fixes classes order based on `eslint-plugin-tailwindcss`
- Remove/updates certain classes that now have shorthands, for example
`lg:h-auto lg:w-auto` is now `lg:size-auto`
- Removes unnecessary curly braces
Co-authored-by: Sam Ko <sam@vercel.com>
When we apply `createActionProxy` twice to the same value, it currently
errors because we can't override the ID of it.
This PR makes sure that 1) when the value already have an ID defined, we
skip setting it again; 2) all the action IDs are being tracked even for
duplicated ones.
Note that it's technically impossible to "detect" the duplication here
(via static analyzation) and only set it once. For example:
```ts
'use server'
export async function foo () {}
export const bar = a_value_we_dont_know_yet ? foo : async () => {}
```
So, the compiler will always wrap `createActionProxy` for every exported
value and assume they're different Server Actions (hence different IDs).
With this fix, if we find that it's already defined before, we just
return the defined reference as they're strictly identical so the ID
does't matter.
Closes#54655, closes#61183.
Closes NEXT-2264
This PR fixes the cookie merging logic in Server Actions. Specifically,
when users do `cookies().set(...)` or `cookies.delete(...)` with a
`redirect()` to an internal route followed. Currently, we are just
concatenating the original cookies (request cookies) and the mutated
cookies. That introduces several issues, like it can't override or
delete an existing cookie.
Closes NEXT-2221
Reverts changes from #61173 & #60240 (while leaving the tests that were
added).
There are too many spots where considering `/default` routes as pages
needs to be carefully considered in different runtimes, and it turns out
that it's not actually needed to handle the case that it was originally
added for. I confirmed that the test that added the case it was intended
to fix (`parallel-routes-catchall-default`, along with the unit tests in
`normalize-catchall-routes`) are still passing as expected.
<!-- 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 #
-->
#61159 fixed the documentation by removing incorrect information stating
that the type parameter must be set to 'page' when the path contains a
dynamic segment. This PR reflects this change in the warning message,
while confirming that the condition for the warning is already correct.
Additionally, I changed the word "affect" to "effect," assuming it was a
typo. In the documentation, I corrected myself and changed the wording
from "argument is required" to "parameter is required".
### What?
When using layouts in multiple parallel route slots, only 1 of the
layouts would render.
### Why?
The `resolveParallelSegments` logic responsible for populating the
loader tree was incorrectly bailing if it found another parallel route
that matched a page component.
### How?
I did my best to update this loader code with some more comments to make
it a bit easier to reason about, and also made some slight refactors.
But the gist of the fix is just ensuring that each parallel route (that
isn't a direct match on the `children` slot) is resolved as an array, so
that when the subtree is created, it doesn't skip over the slot.
Fixes#58506Fixes#59463
Closes NEXT-2222
This PR is refactoring only and doesn't change the logic, therefore no
tests were added.
The improvement here is readability:
- separate functions to fetch external vs internal image (in the future,
we could improve perf of internal image routing)
- types of the arguments are more specific (rather than passing in
complete NextConfig)
> Note: Its easier to review with whitespace hidden:
https://github.com/vercel/next.js/pull/61172/files?w=1
When there's `useSearchParams` hook triggers the bailout to client side
rendering, users might hard to find where it's from since it could
either from users code base or third party libraries. Adding the stack
trace for it so they could at least investigate which line is throwing
from the server bundle. Will improve it in the later future when we can
give more insights.
#### After
```
⨯ useSearchParams() should be wrapped in a suspense boundary at page "/". Read more: https://
nextjs.org/docs/messages/missing-suspense-with-csr-bailout
at a (/private/var/folders/gy/kq4zjn8s0ljf9sfjyyh_nj640000gn/T/next-install-aa5f331b7f6af2
82fd9bab0f69685454d1f50dc8f3c775da23d4e5e807a970cb/.next/server/chunks/846.js:1:9912)
at h (/private/var/folders/gy/kq4zjn8s0ljf9sfjyyh_nj640000gn/T/next-install-aa5f331b7f6af2
82fd9bab0f69685454d1f50dc8f3c775da23d4e5e807a970cb/.next/server/chunks/846.js:1:22018)
at a (/private/var/folders/gy/kq4zjn8s0ljf9sfjyyh_nj640000gn/T/next-install-aa5f331b7f6af2
82fd9bab0f69685454d1f50dc8f3c775da23d4e5e807a970cb/.next/server/app/page.js:1:2518)
```
#### Before
```
⨯ useSearchParams() should be wrapped in a suspense boundary at page "/". Read more: https://
nextjs.org/docs/messages/missing-suspense-with-csr-bailout
```
Closes NEXT-2239
### What & Why
Using parallel routes with edge runtime would cause a build error when
using a default segment, because edge runtime has special handling to
[read the client reference
manifests](12c9040568/packages/next/src/build/utils.ts (L1543-L1555))
for these when determining if a page is static.
### How
In a similar fashion to how we exclude static checks on reserved pages,
I added similar handling for app pages.
Fixes#60917
Closes NEXT-2241
Context:
- on app router, we bundle all the code used both on server and client
- sentry used to be incompatible with that, however a raw require call
on production to Sentry leads to a 350ms impact on cold boots/initial
load
- it might be ok to bundle now, let's try it out
<!-- 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-2250
## What?
`exportPathMap` didn't work when Turbopack was enabled because the
`serializeNextConfig` function mutates the original values, overriding
`exportPathMap`.
This PR changes the serialization to copy the object and mutate only the
copied object.
Also refactored the test that was checking `_next`, the better way to
test that is to have the page render something dynamically, which is
what is added in this PR.
<!-- 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-2225
