### What?
Fixes https://github.com/vercel/next.js/issues/62525
Closes NEXT-2620
Since codes below do not consider searchParams, `redirect` in server
action removes all searchParams passed from client side.
93e4bb823c (diff-c809d50461027cdba7c092e564818b1172133d337abc5c513f829c94c8483dc6R186)
So I just add conditional branch for searchParams.
---
lint, prettier was applied.
Also I have done tests by commands below. and it was all passed.
```
pnpm testonly --testPathPattern "integration" -t "redirect"
```
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What
This PR enables lightningcss features in next-swc. Currently this is for
the native build targets only, for the wasm there are some unknown build
error prevents to enable this.
Closes PACK-2607
### What
When you have bad nesting html in your React code, React wil raise
hydration error since the browser html parser might parse it to sth else
different comparing to server html on client. Previously we're display
only the warning in the error description in dev overlay.
Now we introduced another format of displaying pesudo html that
representing your code, with highlighting the html tag that causes the
error. Since React might gives you the whole component stack of React
tree, so we also introduced a way that can collapse the error.
#### Example
https://github.com/vercel/next.js/assets/4800338/622122d6-4d2e-4c8e-95e8-4864343e478b
### Why
The reason we added this is that even we show the html diff, it could
super large due to React ordering the html on client, so the mismatch
might be a lot. The idea here is similar to what you saw when you passed
down a bad event handler into server component, we displayed a pesudo
html as it could hit your mind faster than just seeing the warning. The
best way is to display the source code, but before we can show the
source, getting component stack display as pseudo html instead of here
could be more helpful.
### After vs Before
<img width="400"
src="https://github.com/vercel/next.js/assets/4800338/714119ad-ff23-46a9-bc5a-5601eb390e71">
<img width="400"
src="https://github.com/vercel/next.js/assets/4800338/575f95fa-889e-4cee-ad19-9c2fea06519a">
Closes NEXT-2621
### Problem
We've identified a bug within Next.js's pages router when utilizing the
shallow routing API, specifically when invoking `router.push` with the
`{ shallow: true }` option, like so:
```javascript
router.push('/?counter=10', undefined, { shallow: true });
```
Shallow routing is designed to update the URL without running data
fetching methods such as getServerSideProps, getStaticProps, or
getInitialProps. However, a side effect of this process is that it skips
the clean-up of the cancelHandler. This leads to router error events
being fired erroneously, causing confusion and potential stability
issues, as the system behaves as if an error occurred when, in fact,
none did.
### Solution
This PR addresses the issue by modifying the shallow routing logic to
also skip the creation of the cancelHandler. Given that shallow routing
operations are synchronous and do not involve data fetching or other
asynchronous tasks that might need to be canceled, the cancelHandler is
unnecessary in this context.
fixes#61772
---------
Co-authored-by: Shu Ding <g@shud.in>
## What?
Currently flight-manifest-plugin relies on looping over all webpack
chunk groups and trying to infer the entrypoint name from them, which
can be brittle in cases where the chunk group doesn't match exactly with
the entrypoint, which happens for the `_not-found` entrypoint for
example.
This PR changes the implementation to use `compilation.entrypoints`
directly. `compilation.entrypoints` is a `Map` where the key is the
entrypoint name and the value is the entrypoint chunk group, exactly
what this logic was looking for in the current implementation.
<!-- 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-2637
### What?
generateSitemaps function returns a 404 for /sitemap/[id].xml in
production
### Why?
While finding the correct sitemap partition from the array, we check the
param against the id. Which works in dev because id and param are both
without trailing .xml. But it fails in production as param has a
trailing .xml (/sitemap/[id] works in production because it falls back
to dynamic loading and param and id are both without .xml)
### How?
If we are in production environment, check the id with a trailing .xml
because that's whats returned from generateStaticParams, an array of
__metadata_id__ with trailing .xml
Fixes#61969
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
### What?
Run transforms with the tokio context so Wasmer works properly.
### Why?
To allow invoking Wasm plugins. `wasmer` had a breaking change.
### How?
Closes PACK-2587
Closes#62081
---------
Co-authored-by: hrmny <8845940+ForsakenHarmony@users.noreply.github.com>
This moves the locale redirect handling out of `base-server` as it
shouldn't be handled here and should be at the routing level. This
avoids the duplicate handling with middleware that causes the incorrect
detection/infinite looping. Test case from separate PR was carried over
to prevent regression.
Fixes: https://github.com/vercel/next.js/issues/55648
Closes: https://github.com/vercel/next.js/pull/62435
Closes: NEXT-2627
Closes: NEXT-2628
---------
Co-authored-by: Nourman Hajar <nourmanhajar@gmail.com>
Co-authored-by: samcx <sam@vercel.com>
### What
Change from processing the file with `next-metatdata-route-loader`
directly into passing the file as loader query, and leave an empty
resource file for it. This will resolve the error that users were seeing
with `manifest.json` convention.
```
Import trace for requested module:
../../../../packages/next/dist/build/webpack/loaders/next-metadata-route-loader.js?page=%2Fmanifest.jso
n%2Froute&isDynamic=0!./app/manifest.json?__next_metadata_route__
getStaticAssetRouteCode page /manifest.json/route this.resourcePath /Users/huozhi/workspace/next.js/tes
t/e2e/app-dir/metadata-json-manifest/app/manifest.json
```
### Why
I looked at the loader process that the final resource processed by
webpack is `json!next-metadata-route-loader...`, which means the builtin
json loader processing json file after the metadata route loader. I
didn't get chance to solve the ordering issue, so I changed the
resourcePath to empty "", and pass the file path as query into the
loader to avoid json-loader processing it after transpilation.
Fixes#59923
Closes NEXT-2630
Closes NEXT-2439
This ensures our dynamic routes that have the same specificity as
`_next/static/:path*` don't get matched unexpectedly when the
`_next/static` asset doesn't exist. We were holding off on making this
change explicit due to compatibility concerns but these are no longer a
concern and the unexpected matching is more of a concern.
Closes: CSM-11
Fixes: https://github.com/vercel/next.js/issues/19270
Closes NEXT-2613
### What
Fixes `redirect()` call under suspense boundary, redirect url should
include the `basePath` in the url.
### Why
`redirect()` under suspense boundaries will go through server html
insertion, which is being used every time by suspense boundary resolved,
new errors will triggered from SSR streaming. It was missing before.
Fixes NEXT-2615
Fixes#62407
### What?
We should treat the warning for CSR bailout the same as the hard-error,
and show the stack trace for either case.
### Why?
It might be useful to track down the source of this warning.
### How?
We have the stack info already, but we only showed it during the error
logging. We should show it for warnings too.
This is similar to #61200
Closes NEXT-2624
Addresses #57066
Currently, a user running `next start` on an un-built Next.js project
receives a confusing uncaught error before the process just ends:
```
▲ Next.js 14.1.0
- Local: http://localhost:3000
[Error: ENOENT: no such file or directory, open '/home/flotwig/src/project/.next/BUILD_ID'] {
errno: -2,
code: 'ENOENT',
syscall: 'open',
path: '/home/flotwig/src/project/.next/BUILD_ID'
}
```
In my case, I ran into this because I had not worked with Next.js for a
while, and I forgot that `next dev` was used for local development, not
`next start`. I believe many of the confused users in #57066 are making
a similar mistake and not realizing it, due to the error message.
This PR catches an `ENOENT` when reading `BUILD_ID` and suggests that
the user `next build` or `next dev` to remove this friction point:
```
▲ Next.js 14.1.1-canary.69
- Local: http://localhost:3000
Error: Could not find a production build in the '.next' directory. Try building your app with 'next build' before starting the production server. https://nextjs.org/docs/messages/production-start-no-build-id
at setupFsCheck (/home/flotwig/src/next.js/packages/next/src/server/lib/router-utils/filesystem.ts:157:13)
at initialize (/home/flotwig/src/next.js/packages/next/src/server/lib/router-server.ts:90:21)
at Server.<anonymous> (/home/flotwig/src/next.js/packages/next/src/server/lib/start-server.ts:295:28)
```
A few things probably need to be resolved before this PR can merge, I
would appreciate any input from Next.js maintainers.
- [x] Is this the best place to catch this? I am not familiar with the
Next.js codebase, so I just caught this in the most obvious way.
- [x] Can the error message be improved?
- [x] Add a test for the error in `test/development`
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What
When the popstate action is fired (as is the case in a browser back
button), if the page you're going back to has missing cache node data,
the router will crash.
### Why
Almost all router actions will suspend at the app-router level with the
exception of `ACTION_RESTORE`. This was to address an issue where
suspending in the router would add enough delay for browser scroll
restoration behavior not to work.
As a result, when going back to the page with missing data, app-router
wouldn't suspend but layout-router would suspend on the missing data
while triggering a lazy fetch. We trigger a server-patch with the
applied lazy data, but when React replays the render, it will replay the
branch without the cache node data applied. This results in the router
getting caught in a loop of suspending, applying the cache node,
replaying the branch without the cache node, and eventually crashing due
to an error thrown by React to prevent re-suspending indefinitely.
### How
This adds a property to the cache node to signal if the lazy data has
been resolved. If it has been, we won't call the server patch action
again.
Fixes#61336
Closes NEXT-2438
Currently to redirect to another RSC route of the same app, we initiate
another request to that route. This PR changes that request to directly
use the internal hostname of the current server handler, rather than
relying on other headers.
Closes NEXT-2614
### What
Introduce a `react-server` export condition of `next/navigation`, which
only take effects in RSC layer. And it will only contain `notFound` and
`redirect` related APIs, which can be shared in both server components
and client components environment. This export excludes those APIs
working with React context which are only working in client components.
### Why
We fixed an issue bad alias for react-server condition of react itself
in
https://github.com/vercel/next.js/pull/61522/files#diff-ecb951c8d26893f6d1e4425a873b399d52346ef63eb90fba79d980cef2fabe8cL35
, this was a good fix. But we found that if you're using edge runtime
with `next/navigation` it will error with bundling that you're attempted
to import some client component hooks such as `useContext` from react.
So we introduced a `react-server` version of `next/navigation` that
doesn't interoplate with any client hooks, can we'll bundle that one
instead of original `next/navigation` when you're using it in server
components or app routes.
Closes NEXT-2583
Closes NEXT-2519
Fixes#62187
### What?
Hide frames that start with `node:internal`.
### Why?
These are usually unactionable anyway.
### How?
Filter these lines the same way we filtered `stringify <anonymous>` in
#62325
Closes NEXT-2593
### What?
Reduces the number of css chunks per entrypoint by merging chunks.
### Why?
In larger application the total CSS deduplication approach falls short
in a sense of it's causing way too many separate chunks, which results
in way to many requests. That affects page load performance.
Closes PACK-2598
With Server Actions, a module-level encryption can happen when you do:
```js
function wrapAction(value) {
return async function () {
'use server'
console.log(value)
}
}
const action = wrapAction('some-module-level-encryption-value')
```
...as that action will be created when requiring this module, and it
contains an encrypted argument from its closure (`value`). This
currently throws an error during build:
```
Error: Missing manifest for Server Actions. This is a bug in Next.js
at d (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/chunks/1772.js:1:15202)
at f (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/chunks/1772.js:1:16917)
at 714 (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:2806)
at t (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/webpack-runtime.js:1:127)
at 7940 (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:941)
at t (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/webpack-runtime.js:1:127)
at r (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:4529)
at /Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:4572
at t.X (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/webpack-runtime.js:1:1181)
at /Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:4542
```
Because during module require phase, the encryption logic can't run as
it doesn't have Server/Client references available yet (which are set
during the rendering phase).
Since both references are global singletons to the server and are
already loaded early, this fix makes sure that they're registered via
`setReferenceManifestsSingleton` before requiring the module.
Closes NEXT-2579
This continues https://github.com/vercel/next.js/pull/62336 and ensures
we chunk fully but removes the cache groups as that introduces some
un-necessary duplication. With this configuration we ensure we split
chunks of all types which fixes the OOM/cache size issue and also avoids
overall chunk size increase.
Closes NEXT-2577
Previously, runtime errors would not be recovered from. Like the webpack
implementation, this addresses the issue by performing a full page
reload when recovering from a runtime error.
Test Plan: `test/development/acceptance-app/error-recovery.test.ts --
Error recovery app default stuck error`
Closes PACK-2569
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