Closes NEXT-4534
This PR introduces the ability for next.js to forward logs, errors, and
unhandled rejections from the browser to the terminal the dev server is
running in (behind an experimental flag)
# Explanation
The 2 main components of this pr are the client side error accumulation
logic, and the ingest handling on the other side of the hmr socket.
We listen on the existing hmr socket to send batched logs, errors, and
uncaught rejections the frame after they were captured. All forwarded
data is sent with metadata so we can have reconstruct the log with an
equivalent level of information to the browser- since we expect AI
agents that can't access the browsers to be consumers of this feature
(and it's generally useful).
All foreign data created by the user in the browser is serialized using
`safe-stable-serializer`, a popular serializer [used by other logging
libraries](https://www.npmjs.com/browse/depended/safe-stable-stringify),
like
[pino](https://github.com/search?q=repo%3Apinojs%2Fpino+safe-stable&type=code)
(safety, determinism, fast). We also have a light shim on top of json
serialization to handle displaying custom data representations that
either wouldn't survive serialization (undefined) or we want to present
to users in a custom format (throwing proxies, promises, ...)
On the dev server server, we (bespoke) deserialize, source map, format,
and log. I tried to share as much logic as I could with error dev
overlay to avoid feature drift since they are very similar
implementations other than the render target
# Explicitly covered cases
- console table
- shows as `[browser]\n<table>\n(<source location>)`
- console trace
- shows as `[browser] arg1 arg2 ...\n<stack trace>\n([source mapped
location of log]`)`
- trace is source mapped
- ignored frames are shown, incase people explicitly want the full trace
- console dir
- shows as `[browser] arg1 arg2 ([source mapped location of log])`
- we need to explicitly capture stdout and rewrite it when we call nodes
`console.dir` to prefix and postfix with [browser] and and (`<source
mapped location of log>`) without adding newlines (we could do this for
console.table but it makes sense to keep the prefix and postfix on new
lines)
- console error
- `[browser] arg1 arg2 \n codeblock + source mapped stack of
console.error ([source mapped location of console.error])`
- if there are any `Error` values present we wont show the stack and
code block of console.error since it's overwhelming (this is fine since
we still tell the user where the `console.error` is with the appended
location)
- rejected promises that have `Error`'s
- behave identical to console.error, but is prepended with `⨯
unhandledRejection`
- the `Error`'s render with their source mapped stack + ignored frames
- no error stack can be automatically appended where the promise
rejected
- rejected promises that have non `Error` values
- prepended with `⨯ unhandledRejection: ${error.name}: ${error.message}`
- everything is logged in red
- no error stack can be automatically appended where the promise
rejected
- on caught error
- prepended with `Uncaught ${errorName}: ${errorMessage}`
- stack attached to error is source mapped + ignored frames are not
shown
- everything is logged in red but the code block of where the error
orginated from
- all other console cases
- shows as `[browser] arg1 arg2 ([source mapped location of log])`
- if an error is passed, we show the error name, message, source mapped
stack (colored white, ignored frames not shown), and code block if
available (syntax highlighted)
- we apply util.format to handle formatted strings
- logs captured during RSC rendering
- not piped to server, ignored on client
Closes NEXT-4534
Capture defined boundaries (not-found / error / loading) and used to filter which one is available for boundary triggers
The trie will now hold all the defined boundaries, but what's different from the existing rendered boundaries is:
Here's the difference of new defined boundary trie nodes:
```
{
type: "boundary:<type>"
pagePath: "<pagePath>@boundary"
}
```
We add a `boundary:` prefix to determine if it's node representing existence;
We add a `@boundary` suffix to the filename cause the <pagePath> part is still need to use for indexing in the trie, but the `@boundary` doesn't matter yet. We'll remove it once we start using the file name in the dropdown panel
Closes NEXT-4330
### Example
When there's only one not-found.tsx, allow to trigger the not-found boundary and disable the rest.
https://github.com/user-attachments/assets/eb5c49a7-4fd2-496b-b778-fb66581908b3
<!-- 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 #
-->
update Rspack to 1.4.2, in this version we fix bugs when using Rspack
persistent cache in next.js.
Now user can try Rspack persistent cache by follow way:
```js
const config = {
webpack: (config) => {
config.experiments.cache = {
type: 'persistent'
};
return config;
},
};
```
With recent improvements in React, and after switching to the React
builds for Node.js in #81048, we can now generate better dynamic
validation error stacks in dev mode by utilizing owner stacks instead of
component stacks.
For async I/O, we're using the owner stack exclusively. For sync I/O
we're appending the owner stack to the call stack. In a future iteration
we might instead log the original error as-is where it occurs, and let
`patchErrorInspectNodeJS` handle the owner stack appending as a general
solution.
Additionally, we're now guiding users in the build-time error messages
to using `next dev` for further debugging of dynamic validation errors –
or, alternatively, using `next build --debug-prerender`.
closes NAR-149
webpack-only at the moment since I have no easy stack to test this on in Turbopack until we sourcemap the Turbopack runtime.
This applies the same heuristic Chrome uses. For sources whose associated sourcemap ignores everyone of its sources, we ignore-list that source even if we didn't find a mapping. This is similar to other common heuristic where the closest mapping is used when no exact mapping exists.
Closes https://linear.app/vercel/issue/NEXT-4560/
React now exposes Web stream APIs in their Node.js builds so we can use the Node.js builds.
That enable us to use some of the Node.js goodies like `async_hooks` which is required for the React's experimental Server Requests track.
## Test plan
`next-server` runtimes did not increase bundle size. We even saved some in the `app-page` entries since we no longer have to bundle Edge and Node.js versions of React Server. We can rely solely on the Node.js variant of React Server.
A build of `test/e2e/app-dir/hello-world` shows no significant bundle size changes
A regression from #81085 @huozhi
The problem is that `openDevToolsIndicatorPopover` doesn't tell anymore whether the popup menu is open, but if the panel is open, but the "Try Turbopack" text is in the popup menu (only in the old UI).
These frames will be ignore-listed soon. Until then, we remove them from the test snapshots, because their occurrence seems to be non-deterministic. They come from React's RSC parsing.
Track built-in conventions in segment explorer. The default `global-not-found.js` and `global-error.js` will be displayed.
Their style will be different to the others, we'll follow up in the later PRs.
Closes NEXT-4576
Group all the built-in conventions into `src/client/components/builtin` with the actual same name of the conventions they represent.
e.g.
The default `not-found.js` is `next/dist/client/compoents/builtin/not-found.js`;
The default `global-error.js` is `next/dist/client/compoents/builtin/global-error.js`;
This give us an easier way to track all the builtin conventions. This is also the preparation work for #80961 where we display the builtin conventions in the segment explorer.
# Enhance Layer Names with User-Friendly Descriptions
This PR improves the developer experience by enhancing layer names in Turbopack with user-friendly descriptions. Instead of just using internal identifiers like "app-client" or "app-rsc", the PR adds descriptive names like "Client Component Browser" or "Server Component" that better communicate the purpose of each layer to developers.
Key changes:
- Created a new `LayerName` struct that contains both the internal name and an optional user-friendly description
- Updated all layer references throughout the codebase to use this new structure
- Changed error message text from "Example import trace(s)" to "Import trace(s)" for more simplicty
These changes make error messages and debugging information more intuitive, helping developers better understand which part of the application is experiencing issues.
fixes#80275
.. to generate https image urls in meta data when using the
--experimental-https flag
---------
Co-authored-by: Zack Tanner <[email protected]>
Co-authored-by: JJ Kasper <[email protected]>
This pull request updates error recovery tests to improve compatibility
with the Rspack bundler by introducing an `isRspack` flag and modifying
test cases to handle Rspack-specific error formats. The changes ensure
that runtime and build errors are correctly detected and displayed when
using Rspack.
### Rspack Compatibility Updates:
* Introduced the `isRspack` flag to determine if Rspack is being used,
based on the `NEXT_RSPACK` environment variable. This flag replaces
direct checks of `process.env.NEXT_RSPACK` for better readability and
maintainability.
(`test/development/acceptance-app/error-recovery.test.ts`
[[1]](diffhunk://#diff-ed42d009889881804f76e500465e132e4aa1df75c8659119e1b5cff4d230b7cdR8-R9)
`test/development/acceptance/error-recovery.test.ts`
[[2]](diffhunk://#diff-18cc654bcba9dbffcf77a6157fec144f9d0b1a0b3c59d46b33f6a2b95f543a91R9)
* Updated test cases in `error-recovery.test.ts` and
`acceptance-app/error-recovery.test.ts` to handle Rspack-specific error
messages. This includes adapting error expectations for syntax errors,
runtime errors, and build errors with the Rspack error format.
(`test/development/acceptance-app/error-recovery.test.ts`
[[1]](diffhunk://#diff-ed42d009889881804f76e500465e132e4aa1df75c8659119e1b5cff4d230b7cdR58-R79)
[[2]](diffhunk://#diff-ed42d009889881804f76e500465e132e4aa1df75c8659119e1b5cff4d230b7cdR574-R588)
[[3]](diffhunk://#diff-ed42d009889881804f76e500465e132e4aa1df75c8659119e1b5cff4d230b7cdR845-R872);
`test/development/acceptance/error-recovery.test.ts`
[[4]](diffhunk://#diff-18cc654bcba9dbffcf77a6157fec144f9d0b1a0b3c59d46b33f6a2b95f543a91L58-R74)
[[5]](diffhunk://#diff-18cc654bcba9dbffcf77a6157fec144f9d0b1a0b3c59d46b33f6a2b95f543a91L372-R394)
[[6]](diffhunk://#diff-18cc654bcba9dbffcf77a6157fec144f9d0b1a0b3c59d46b33f6a2b95f543a91L755-R766)
* Replaced outdated error message formats in Rspack-related test cases
with updated and more precise error descriptions, including detailed
stack traces and error causes.
(`test/development/acceptance/error-recovery.test.ts`
[[1]](diffhunk://#diff-18cc654bcba9dbffcf77a6157fec144f9d0b1a0b3c59d46b33f6a2b95f543a91L815-R835)
[[2]](diffhunk://#diff-18cc654bcba9dbffcf77a6157fec144f9d0b1a0b3c59d46b33f6a2b95f543a91L883-R903)
These changes improve test coverage for Rspack and ensure robust error
handling across different bundlers.
### What?
Use CSS string for CSS errors instead of Rust debug representation, and remove `lightningcss` text from the error message.
### Why?
We don't need them.
We never actually invoked the listeners attached by React. Updates only worked on soft-navigation because we also re-render the DevOverlayRoot and don't bail out anywhere at the moment.
Just invoking the listeners is not sufficient after https://github.com/vercel/next.js/pull/79699 since userspace and dev-overlay would read different versions of `listeners`. I ported the segment explorer into the new folder structure. Updates now flow through the `dispatcher` and then invoking the listeners actually works. Though mid term we should move the segment tree into actual React tree to get rid of the sync updates.
I also noticed that we're missing an implementation for a remove operation which is required to show the correct state during soft navigations.
### What
When there's a same error throwing constantly, we should avoid unnecessary re-renders on the exact same error. In dev overlay we already have strategies that can dedupe the error. And we noticed the error is shown correctly but just the dialog got re-rendered with animations.
After digging deeper, noticed we are still adding the same runtime error into the error collection, just because each time it got the new "ID", as the "ID" itself is incremental based on actions. Each action will get a new error ID. Hence we're adding a condition in deduping. If we found that the new error already existed in the previous events, we'll return with the same previous events instance to tell dev overlay that errors are not changed.
Fixes NEXT-4493
#### After
https://github.com/user-attachments/assets/c1f004b5-2de6-445a-aad0-efdfd0ecb8c9
#### Before
https://github.com/user-attachments/assets/1249ed54-ba63-4eb6-a08a-64560ab4014a
