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.
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
When turbopack reports an issue, compute a set of import-traces for that file so the user can better understand the context of the issue and trivially answer questions like:
* Why is this file included at all?
* Why does next think this is a client-component?
To do this we leverage the `SingleModuleGraph` and use the `astar` algorithm from `petgraph` to compute the shortest path to a root module. This isn't the most optimal approach but should be sufficient since we don't anticipate this being a performance issue.
A complex part of this is that the module-graph tracks the relationships between _modules_ but Issues are associated with _files_. While modules are also associated with files this is a many-to-one relationship. This is why we might report _multiple_ traces for a single issue and also why a single file might appear multiple times in a trace.
## Open formatting questions
* how should we represent paths from other 'filesystems'?
- for disk filesystems i could compute relative paths to the root of the current directory? the `[project]` filesystem? For now i just use the filesystem name as a hypothetically cromulent root.
## Alternatives
The main alternative investigated was associating Issues with `Modules` by collecting them during graph construction. This unfortunately proved to be a non-trivial performance regression and so it was abandoned. The core problem is that we would need to introduce additional `OperationVc` and task roots to simply `collect` the issues. This also wouldn't eliminate the duplicate traces issue, and instead we might end up reporting duplicate issues instead.
## Performance
TODO
Closes PACK-4105
Sebastian "Sebbie" Silbermann