### What?
Fixes#58570
### How?
Include the **basePath** to the **fetchUrl** to ensure the relative URL
matches the app when deployed under a **basePath**.
### Tested?
I have added an **e2e** test with a basic custom server & server action
redirect.
This test was confirmed to **catch** the bug when running it without the
fix in place. When running it you will get the failed result.
```
FAIL test/e2e/app-dir/app-basepath-custom-server/index.test.ts (12.293 s)
custom-app-render
✕ redirects properly when server action handler uses `redirect` (1661 ms)
● custom-app-render › redirects properly when server action handler uses `redirect`
expect(received).not.toEqual(expected) // deep equality
Expected: not ["/base/another", 200]
45 | // if broken, this will include a 200 from the /base/another indicating a full page redirect
46 | responses.forEach((res) => {
> 47 | expect(res).not.toEqual(['/base/another', 200])
| ^
48 | })
49 | })
50 | }
at toEqual (e2e/app-dir/app-basepath-custom-server/index.test.ts:47:25)
at Array.forEach (<anonymous>)
at Object.forEach (e2e/app-dir/app-basepath-custom-server/index.test.ts:46:17)
Test Suites: 1 failed, 1 total
Tests: 1 failed, 1 total
Snapshots: 0 total
Time: 12.321 s, estimated 22 s
Ran all test suites matching /test\/e2e\/app-dir\/app-basepath-custom-server/i.
ELIFECYCLE Command failed with exit code 1.
ELIFECYCLE Command failed with exit code 1.
ELIFECYCLE Command failed with exit code 1.
```
### Notes
Not sure if there are any edge cases where the `fetchUrl` is now broken
in other use cases where there is no **basePath**, I assume the string
would be empty `""` and result in the same URL as before, but not sure?
### Disclosure
~I am not that familiar with the Next.js code base and this is my first
PR. I was struggling to find out how to grab the **basePath** from
`next.config.js`, but then noticed the **assetPrefix** inside the
function matched, so decided to use that for minimal change. I don't
know if there are any caveats with this approach, but could consider
switching to pull directly from the config file, if that's possible?~
**Update:** Figured out where the **basePath** came from and switched
it.
---------
Co-authored-by: Colton Ehrman <cehrman@paypal.com>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
### What?
enable the custom allocator flag to enable mialloc.
allow to configure custom allocator on napi level.
### Why?
It's faster and we had it enabled before.
It was disable before as `next-core` is used with no default features in
workspace
Native Build: https://github.com/vercel/next.js/actions/runs/7388725004
Closes PACK-2185
---------
Co-authored-by: OJ Kwon <1210596+kwonoj@users.noreply.github.com>
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
Addition to docs (robots.mdx) - Customize user-agent rules
For issue #59178
Docs: Guidance on allowing multiple user agent rules with varying
allow/disallow.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
---------
Co-authored-by: Delba de Oliveira <32464864+delbaoliveira@users.noreply.github.com>
Co-authored-by: Sam Ko <sam@vercel.com>
Co-authored-by: Delba de Oliveira <delbabrown@gmail.com>
This pull request updates the dependencies in the cache-handler-redis
example. It updates the versions of the `@neshca/cache-handler`, which
introduces new features.
---------
Co-authored-by: Delba de Oliveira <32464864+delbaoliveira@users.noreply.github.com>
This PR fix `image-component` example viewsource paths and shimmer page
filename. Which would result a Github 404 page in the current live
example.
A flow up fix on this PR #60289
### What?
Adds the name of the test that's running when the browser is started to
the recording.
Also makes `RECORD_REPLAY=1` work without `run-tests.js`
Closes PACK-2206
### 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>
<!-- 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?
This PR refactors organization for the rust side packages to build
`next-swc`.
### Why?
We had some historical legacy around package structures, have ambiguous
name for `core` / `next-core`. One contains swc transform visitor for
the next.js, and the other one is new for turbopack's core next.js
features. In addition to that, there was a package dependency chain
prevents to use `core` in the turobpack / next-swc both, so each time
porting a transformer into turbopack it requires to extract new
dependency to be imported in the both place.
PR touches its organization - while PR is large to touch various files,
the crux is summarized at
2cedd06ea5
:
1. `core` becomes `next-custom-transforms`, also this becomes an
agnostic pkg can be imported in turbopack / wasm / next-swc
2. simplify dependency chain to import next-custom-transforms, organized
as below
```mermaid
flowchart TD
C(next-custom-transforms) --> A(napi)
C(next-custom-transforms) --> B(wasm)
D(next-core) --> A(napi)
E(next-build) --> A(napi)
F(next-api) --> A(napi)
C(next-custom-transforms) --> D
D(next-core) --> F(next-api)
D(next-core) --> E(next-build)
```
`impl CustomTransformer` for the each transform still lives in
`next-core`, so turbopack specific dependency is isolated under
`next-core/build/api`.
Closes PACK-2201
Closes PACK-2202
---------
Co-authored-by: hrmny <8845940+ForsakenHarmony@users.noreply.github.com>
### 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
### What?
In the previous PR (#60249), it was found that the case when the
response size is larger than 2MB is not sufficiently covered by tests
[[comment](https://github.com/vercel/next.js/pull/60249#pullrequestreview-1807140518)]
### How?
I added a few more checks.
Just checking the number of API calls is not enough - I believe it is
important to additionally verify what exactly the page received.
If I'm honest, I couldn't find the exact reason why data is loaded after
application start when using `customCacheHandler`, but without it -
during build. It seems like something in the butcher. Therefore, in this
part, I simply configured it for the current version.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
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
## What?
Adds instructions for how to run tests with Turbopack and how to run
tests while recording using Replay.io.
I've also updated the instructions to mention `test-dev` and
`test-start` which are the commands we generally use.
<!-- 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-2031
