This PR introduces 2 experimental options for doing more work in the
webpack build in parallel instead of in serial. These options may
improve the performance of builds at the cost of more memory.
`parallelServerAndEdgeCompiles`: This option kicks off the builds for
both `server` and `edge-server` at the same time instead of waiting for
each to complete before the next one. In applications that have many
server and edge functions, this can increase performance by doing that
work in parallel. This can be used with `next build` or `next
experimental-compile`.
`parallelServerBuildTraces`: This option starts the server build traces
as soon as the server compile completes and runs it in the background
while the other compilations are happening. With this option enabled,
some unnecessary work may be done since ordinarily the client
compilation provides information that can reduce the amount of tracing
necessary. However, since it is in parallel with the other work, it may
still result in a faster build in total at the cost of more memory. This
option is already the default when using `next experimental-compile` but
can now be used when `next build` is used also.
---------
Co-authored-by: Delba de Oliveira <32464864+delbaoliveira@users.noreply.github.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What
`/default` segments were considered valid page outputs to handle
catch-all route normalization (see #60240) but they shouldn't leak into
the prerender manifest. This filters them out at build time.
Closes NEXT-2053
In the output shared js chunks section we're showing all shared chunks
atm, some of them might be too small (few bytes) due to code split. e.g.
in the below example, main-app is only `218B`, we're going to group all
the chunks below 10KB together into one item line
#### Before
```
+ First Load JS shared by all 81.9 kB
├ chunks/381-ffe155bc1c63f064.js 26.7 kB
├ chunks/8766613a-1f3d501627fe8359.js 53.3 kB
├ chunks/main-app-80d2c0fe59f30ae2.js 218 B
└ chunks/webpack-e6edcd8ebd35b832.js 1.68 kB
```
#### After
```
+ First Load JS shared by all 83.7 kB
├ chunks/4921c021-73266f862a05e4e2.js 53.3 kB
├ chunks/596-73310d23ef824244.js 28.6 kB
└ other shared chunks (total) 1.83 kB
```
Closes NEXT-2046
Closes NEXT-1970
### What?
When using catch-all routes in conjunction with parallel routes, and
when importing a client component (`"use client"`), the build would fail
with the following error:
> Could not find the module "PathToClientComponent" in the React Client
Manifest. This is probably a bug in the React Server Components bundler.
### Why?
`flight-manifest-plugin` generates manifests for each page entry. The
`clientModules` portion of this manifest is used by React to load the
appropriate client module. When React attempts to render a component
tree and detects a module that it cannot find, it will throw this error.
To illustrate why it isn't in the tree, consider the following example:
```
app
page.tsx
layout.tsx
@slot
[...catchAll]
page.tsx
```
```tsx
// app/layout.tsx
export default function Layout({children, slot}) {
return <>{children} {slot}</>
}
```
```tsx
// app/@slot/[...catchAll]/page.tsx
import Link from 'next/link'
export default function Page() {
return <Link href="/">Test</Link>
}
```
When visiting `/`, we'd expect both the catch-all `@slot` and the root
page to render. At build time, we'll generate a client reference
manifest for `/` and `/[...catchAll]` since both are page components.
However, the `@slot` imports a client component. When we attempt to load
the client reference manifest for `/`, it will ignore the catch-all
slot's manifest, resulting in the error.
### How?
The `entryNameToGroupName` function seems to already exist to handle
this scenario for other cases. For example,
`app/(group)/@named/foo/page` needs to know about any manifests
associated with `app/foo`. This updates the code to apply similar
handling to catchAll segments. When applying this change to the example
mentioned earlier, it will properly merge the manifests for both
`app/@slot/[...catchAll]/page.tsx` and `app/page.tsx` because both will
be part of the `/` group.
Closes NEXT-1908
Fixes#59747Fixes#59510
### Fixing a bug
### What?
When basePath is added, intercepted routes stop working correctly.
### Why?
For them, basePath was not added at all.
### How?
Added basePath to the rewrites for intercepted routes.
Fixes#52624, #58268
### What?
This PR adds a new flag called
`experimental.missingSuspenseWithCSRBailout`.
### Why?
Via this PR we can break a build when calling `useSearchParams` without
wrapping it in a suspense boundary.
If no suspense boundaries are present, Next.js must avoid doing SSR and
defer the entire page's rendering to the client. This is not a great
default. Instead, we will now break the build so that you are forced to
add a boundary.
### How?
Add an experimental flag. If a `BailoutToCSRError` error is thrown and
this flag is enabled, the build should fail and log an error, instead of
showing a warning and bail the entire page to client-side rendering.
Closes NEXT-1770
---------
Co-authored-by: Balázs Orbán <info@balazsorban.com>
Co-authored-by: Wyatt Johnson <accounts+github@wyattjoh.ca>
### Fixing a bug
### What?
Custom cache handler doesn't work on Windows
### Why?
It broke in a recent fix, when adding ESM support - #59863. The problem
is not new - dynamic imports consider an absolute path in Windows as a
protocol:
`ERR! Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only URLs with a scheme
in: file, data are supported by the default ESM loader. On Windows,
absolute paths must be valid file:// URLs. Received protocol 'C:'`
### How?
As a solution, it is necessary to explicitly indicate that it is indeed
an absolute path, for example by adding a / at the beginning, but the
most reliable way is to use pathToFileURL.
Since the logic is repeated in 4 places - I created a common function.
Fixes#58509
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
Previously, if an error such as the client side rendering bailout (not
to be confused with the static rendering bailout which PPR supercedes)
occurs during render, and the `postpone` function was invoked during the
original render, then the `staticGenerationStore` would incorrectly
report that the render did call `postpone`, because the value is not
reset on the render for the error page.
### How?
Returning no error when the standard render is used and returning the
error when the error render was used ensures that we don't warn about
missing postpone data when a client side rendering bailout occurs.
### Looking Ahead
A refactor of the `AsyncLocalStorage` should be done such that the
stores are:
1. Returned by the calling function so we aren't reaching into store
properties at different parts
2. Reorganizing the stores so that they're tied to the invocation
lifetime, not the entire request lifetime, so that operations (like
postpone) should only be available during renders that support postpone,
not all renders during a request.
Closes NEXT-1927
The original motivation of this PR is to get `unstable_cache` into a
state where I can more easily change the implementation of postpone to
be more akin to "dynamic rendering APIs". the existing approach made
typing the staticGenerationStore in a way I wanted to for the planned
changes would have been hard to implement with the current approach. At
the same time this was an opportunity to make the implementation more
efficient and easier to reason about.
reorganizes unstable_cache to improve performance and potentially fix
latent bugs related to nest cache calls
In the original implementation there are repeated defined checks for the
store and relatively complex logic around gathering the cache entry. In
my refactor I fork the implementation based on whether we have a store
or not. Loosely this translates to whether the cache call is for App
Router vs Pages Router however due to a quirk in how we scope inner
cache calls there is an existing and unchanged case where a Pages Router
cached callback runs with a "fake" store that is used to scope some
cache values to prevent inner caching when one cached function calls
another. It should be noted that this fake store technique means that
inner cache calls inside Pages Router will hit the App Router pathway in
unstable cache. This is not great but it is the current behavior and
while I have made some changes that might fix some bugs changing this
felt like a much bigger lift to do in a primarily refactor PR.
This "fake" store can be replaced by a different async store for Pages
Router which we can use to scope the inner environment to not be cached
eventually though it may make more sense to just generalize the
staticGenerationStore into a kind of RenderStore and have it run for
Pages Router too.
I moved as much computation that can be done in the closure around the
cached function out of the cached function and I narrowed the scope of
the run call to make it clear that we really only need to scope the
callback.
I removed function allocations per invocation
I probably fixed a bug in how the revalidate property was refined on the
static generation store. Previously it would be possible to go from
number to false and back again but this doesn't make sense as false is
more like INFINITY in terms of refining to shorter values. This PR
updates this logic to be apparently
Closes NEXT-2028
### What?
When accessing `params` on a `RootLayout`, while also using parallel
routes, two potential errors would occur:
- A `Warning: React.createElement: type is invalid` error when
attempting to render a `NotFound` component that doesn't exist
- A `TypeError: Cannot read properties of undefined` error when
attempting to access params in the root layout.
### Why?
`createComponentTree` will render a duplicate `RootLayout` (to ensure
the `notFound()` fallback in unmatched parallel slots have a
`NotFoundBoundary` to catch them) but it currently doesn't ensure a
`NotFound` component exists nor does it forward `params` to the layout.
### How?
This forwards the params to the `RootLayout` and doesn't render a
`NotFoundComponent` if one doesn't exist. This replaces a few `any`
types with more sound types that would have helped catch these mistakes.
There's still a lot more typing that needs to be done (left a comment
below with some additional details) but I opted to make the minimal
changes related to this issue.
Longer term we should remove this duplicate `RootLayout` (see #60220)
which will require special UI to show unmatched slots (similar to the
error overlay, but less harsh)
Closes NEXT-1909
Fixes#59711
When you have a gaint code base of next.js app, the output client side
loaded js bundle size could be large since most of them are functional,
it might not make sense to display yellow or red color to warn you that
your bundle is too large since they conatin the basic functionality.
We display the previous colored ones with opinionless bold white color
to highlight them
Closes NEXT-2017
Closes NEXT-2015
This includes the list of changed modules in the `client-hmr-latency`
event for changes in app router pages as well as when using Turbopack.
For Turbopack, this list is derived from the data structure included in
the `turbopack-message` event. Each of these is originally a module id,
which includes additional context information. For analytics purposes
this is removed (and could maybe surfaced in the future once the webpack
data is also normalized).
Closes PACK-2167
### What?
When running a
[multi-zone](https://github.com/vercel/next.js/tree/canary/examples/with-zones)
app in dev, guest app pages would infinitely reload if you change the
basePath of the host app to the default one (omit basePath settings in
next.config.js) (empty string `""` as per Next.js docs).
### Why?
The HMR upgrade request would fail and get caught into a retry loop. In
the multi-zone case, they fail because the upgrade request would be sent
again for a request that had already been upgraded. This resulted in a
"server.handleUpgrade() was called more than once with the same socket"
error, causing the upgrade request to fail.
Every time a retry occurred, the page would trigger a full refresh since
certain HMR errors cause the browser to reload.
### How?
This ensures the upgrade handler only responds to requests that match
the configured basePath (considering when there is no basePath). Default
basePath for Next.js applications it's an empty string `""`.
Ref: https://nextjs.org/docs/app/api-reference/next-config-js/basePath
Other fixes & updates related to the bug:
- Updated test apps to avoid having issues regarding client & server
mismatch for dates
- Added default use case in e2e tests, where you have a default Next.js
application where the basePath it's the default one and a guest app that
it's being routed by the main one through Next.js rewrites.
Closes NEXT-1797
Fixes#59161Fixes#56615Fixes#54454
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
Per @styfle suggestion, #58038 has been split into multiple PRs for
easier review.
- Remove `chalk` inside `@next/react-dev-overlay`
- `@next/react-dev-overlay` is bundled with Next.js. The usage of
`chalk` inside `@next/react-dev-overlay` was not removed in
https://github.com/vercel/next.js/pull/55992, thus the `chalk` is still
being shipped.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Per @styfle suggestion, #58038 has been split into multiple PRs for
easier review.
- Re-add precompile `watchpack`
- Next.js has stopped bundling the `watchpack` since
https://github.com/vercel/next.js/pull/50792. Currently, `watchpack` is
a direct dependency of Next.js. The PR adds the pre-compile back.
Co-authored-by: Steven <steven@ceriously.com>
Per @styfle suggestion, #58038 has been split into multiple PRs for
easier review.
- Remove `find-cache-dir`
- The usage of `find-cache-dir` was removed **4 years ago**
(https://github.com/vercel/next.js/pull/7013) but the dist and the build
script were never removed.
- Remove `@segment/ajv-human-errors`
- The usage of `@segment/ajv-human-errors` was removed in
https://github.com/vercel/next.js/pull/56383 by me. Though the build
script was also removed in that PR, the dist never got removed.
### What
Fix bad detection of dynamic route of sitemap metadata route, the swc
AST check should process when the text are detected. But prevuious if
there's text with `generateSitemap` such as comment but not the actual
export it will fail.
### How
Add both checks on metadata loader side and detection helper side
* Only call `generateSitemaps` helper when the export existed
* Fix the helper detection logic (major part of this PR)
Fixes#59698Closes#60344
Closes NEXT-2007
### What?
Our
[docs](https://nextjs.org/docs/app/building-your-application/routing/parallel-routes#convention)
point out that `app/page.js` is equivalent to `app/@children/page.js`,
however in practice this is not the case, and causes type errors when
using `@children` slots as well as incorrect behavior when matching
catch-all routes.
### Why?
- When typechecking, `@children` slots would be added to the typeguard
file for the associated layout, resulting in duplicate identifiers for
the `children` prop
- When determining where to insert catchall slots, the `hasMatchedSlots`
check wasn't considering that the `@children` slot corresponds with the
page component, so matching another page would clobber the previous one.
### How?
- Filters out the `@children` slot when collecting slots for
typechecking
- Filters out the `@children` slot when running the `hasMatchedSlots`
function in the catch-all normalizer
Closes NEXT-1984
### Fixing a bug
I'm sorry, I have no idea how I managed to delete this, as I just copied
the code.
However, I had to figure out why the tests passed. When I test the
running application locally, it works as expected.
So, when a route is first used in a running production application in a
test, `ctx.fetchCache` is `undefined`. Therefore, the error rule does
not trigger on the first request, and the cache is successfully written.
This may result in artifacts in FetchCache in Vercel and possibly in
other parts of the code.
```ts
if (
ctx.fetchCache && // <- Undefined on first request
// we don't show this error/warning when a custom cache handler is being used
// as it might not have this limit
!this.hasCustomCacheHandler &&
JSON.stringify(data).length > 2 * 1024 * 1024
) {
if (this.dev) {
throw new Error(`fetch for over 2MB of data can not be cached`)
}
return
}
```
I'm 95% sure that this is a bug and it shouldn't work like this. I'll
look into this later and if there is an error, I'll put it into a task
and try to figure it out later.
Unfortunately, the
[test](7e028fb6d8/test/e2e/app-dir/app-static/app-static.test.ts (L3080))
from [previous PR](https://github.com/vercel/next.js/pull/59976) is not
working yet, although it is correct from my point of view. I think it
should be kept and the problem above should be fixed.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
When relying on a `default` route as a fallback, greedier catch-all
segments in the application hierarchy would take precedence, causing
unexpected errors/matching behavior.
### Why?
When performing parallel route catch-all normalization, we push
potential catch-all matches to paths without considering that a path
might instead be matched by a `default` page. Because of this, the
catch-all take precedence and the app will not try and load the default.
For example, given this structure:
```
{
"/": ["/page"],
"/[[...catchAll]]": ["/[[...catchAll]]/page"],
"/nested/[foo]/[bar]": ["/nested/[foo]/[bar]/@slot/page"],
"/nested/[foo]/[bar]/[baz]": ["/nested/[foo]/[bar]/@slot/[baz]/page"],
}
```
(Where there's a `/nested/[foo]/[bar]/default.tsx`)
The route normalization logic would produce:
```
{
"/": ["/page"],
"/[[...catchAll]]": ["/[[...catchAll]]/page"],
"/nested/[foo]/[bar]": [
"/nested/[foo]/[bar]/@slot/page",
"/[[...catchAll]]/page",
],
"/nested/[foo]/[bar]/[baz]": [
"/nested/[foo]/[bar]/@slot/[baz]/page",
"/[[...catchAll]]/page",
],
}
```
This means that when building the `LoaderTree`, it won't ever try to
find the default for that segment. **This solution operates under the
assumption that if you defined a `default` at a particular layout
segment, you intend for that to render in place of a greedier
catch-all.** (Let me know if this is an incorrect assumption)
### How?
We can't safely normalize catch-all parallel routes without having
context about where the `default` segments are, so this updates
`appPaths` to be inclusive of default segments and then filters them
when doing anything relating to build/export to maintain existing
behavior. We use this information to check if an existing default exists
at the same segment level that we'd push the catch-all to. If one
exists, we don't push the catch-all. Otherwise we proceed as normal.
Closes NEXT-1987
This fixes a case in the PPR navigations implementation where page data
was not being applied.
During a navigation, we compare the route trees of the old and new pages
to determine which layouts are shared. If the segment keys of two
layouts are the same, they are reused.
However, the server doesn't bother to assign segment keys to the leaf
segments (which we refer to as "page" segments) because they are never
part of a shared layout. It assigns all of them a special constant
(`__PAGE__`).
In the PPR implementation, I overlooked this and compared the segment
keys of all segments, including pages, not just shared layouts. So if
the only thing that changed during a navigation was the page data, and
not any parent layout, the client would fail to apply the navigation.
The fix is to add a special case for page segments before comparing
nested layouts. I also moved an existing special case for default pages,
since those are also leaf segments and are conceptually similar.
### Fixing a bug
### What?
Disable 2MB limit for custom incrementalCacheHandler
### Why?
The limit is necessary because `FetchCache` has a 2MB limit, but it
seems there was a miscommunication regarding the key coincidence, where
`fetchCache` is a flag indicating that the method is called from fetch,
rather than indicating that the `FetchCache` Provider is currently being
used.
We do not use Vercel, and as I understand it, we do not have the
opportunity to use this functionality.
In any case, it is more important for us to increase the limits, and in
some cases, using a file storage is even preferable.
### How?
I have created a flag that determines whether the use of `FetchCache` is
possible at least in theory - if no custom provider is passed, and
additionally configured it so that it is not an implementation of
`FetchCache` as a protection against special individuals (*like me :)*).
If everything is fine, I will write proper tests.
Also, I would like to recommend making `FileSystemCache` public (_i.e.
support it as public functionality_) so that it can be imported and
extended or simply used to fix only it.
Fixes#48324 (partially)
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Fixes#57038
# What?
Added an error message when `generateStaticParams` returns an empty
array with `output:export`.
# Why?
To provide developers with clear feedback when `generateStaticParams` is
not used correctly.
# How?
Modified the condition checks around the use of `generateStaticParams`
to include a check for an empty array and added a corresponding error
message.
---------
Co-authored-by: Steven <steven@ceriously.com>
### What & Why?
When visiting a route that attempts to render a slot with no page & no default, the fallback behavior is to trigger a 404. However this can lead to a confusing development experience for complex parallel routing cases as you might not realize a default is missing, or which slot is causing the error.
Previous issues where this caused confusion:
- https://github.com/vercel/next.js/issues/51805
- https://github.com/vercel/next.js/issues/49569
### How?
This is a dev-only modification to track parallel slots that are using the default fallback (aka missing). When the `NotFoundBoundary` is triggered in development mode, this will log a warning about why it 404ed, along with a list of slot(s) that were determined to be missing.
### Future
We should eventually lift this into some sort of dev-only UI to help catch it when not monitoring the browser console (similar to the error overlay). However, this will require some design thought and isn't necessary for the first iteration.
Closes NEXT-1798
