- Moved source files from `_experimental/` to `ui/`.
- Moved `dev-indicators` sources out of `internal/`.
- Renamed files and variables to have explicit `app-`, `App`, `pages-`
or `Pages` prefixes for better distinguish.
- Updated snapshots that were caused by the name change.
- Added better type to `next-runtime.webpack-config.js`.
- Moved `font/` out of `ui/`.
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
Co-authored-by: Jimmy Lai <laijimmy0@gmail.com>
This PR removed the old overlay including the deprecated `buildActivity`
and `appIsrStatus` options.
Closes NDX-785
Closes NDX-855
Closes NDX-865
Closes NDX-866
Closes NDX-867
Closes NDX-868
- `newDevOverlay: true` by default (enables experimental React builds on
canary until owner stacks progress further)
- `run-tests` now sets the env var for tests that were relying on it for
forking behavior
- PPR runners now run with the flag disabled to help catch regressions
in the old overlay until we remove it
- Fixed a number of tests that had outdated snapshots or missed forking
behavior because they weren't running in CI
- Disabled a test that was failing in Turbopack + Experimental React
that is unrelated to the overlay (see:
https://github.com/vercel/next.js/pull/75989)
---------
Co-authored-by: devjiwonchoi <devjiwonchoi@gmail.com>
### What
Addressing the hack we introduced in #71483, where we always display the
hydration error with squashed hydration info into the first error. Now
we're displaying the errors with its own corresponding hydration info
properly, so we don't have to order it in a certain place, but just test
the displayed error itself.
Closes NDX-484
### What
We should treat each line's first character to determine the leading
sign, rather than treating the trimed line's first character as sign.
The bad case was the close tag `>` was treated as leading error sign
```
> <p // should be treated as errored line ✅
> // should not be treated as errored line ❌
```
Also align the attribute name for highlighted lines
This seems to fix at least some cases of `called Option::unwrap() on a None value`.
I suspect this is because of the eventual consistency model in dev?
It also adds better error messages for the various situations.
### What
missing html tags error should always show the overlay when exist, and
the dev indicator count should be 1 since we require users to resolve
this first then React can hydrate the right content. After this they can
move to others.
Since the indicator count is not covered in old test, I add a new test
for new overlay rn, later we can merge them
#### Observed
* Currently it requires to click the indicator to show the error
* The indicator count shows 2
#### Expected
* The overlay should pop up as it's a runtime error
* The indicator count shows 1
When adding or removing a `"use cache"` directive to a function or
module, Turbopack was not able to finish the compilation and hung. This
is now fixed, and we're adding the test to prevent regression.
This PR adds a lot of polish to the experimental Error Overlay:
https://github.com/user-attachments/assets/2540b966-c61d-43eb-b816-5ef25f3ecb11
### Motion
- Stacked layers transition smoothly when switching between errors
- Height transition for the dialog panel to complement the stacked
layers transition
- Dialog contents and the backdrop fade in as per Geist Motion
Guidelines (`scale`, `opacity`)
### Design
- New language icon based on file extension à la (`app.tsx`)
- Shadows are clipped with translucent borders to visually be more crisp
- Use `backdrop-filter: blur()` for backdrop to blend with application
content
- Use `font-variant-numeric: tabular-nums` for ←→ switcher to avoid
layout shift
- Misc alignment improvements
### Interactions
- Focus is now trapped in the dialog, <kbd>Escape</kbd> will un-trap and
re-focus the last `root.activeElement`
- Focus states for all interactive elements
- Fluid reveal & collapse of ignored Call Stack items ↓
https://github.com/user-attachments/assets/59a81cea-24ec-4fe4-be00-b911ab484757
Closes NDX-711
Closes NDX-744
---------
Co-authored-by: devjiwonchoi <devjiwonchoi@gmail.com>
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
Today, when editing server components that use `"use cache"` functions,
only updates to the uncached parts of the component will be reflected in
the rendered result after the HMR refresh was applied. Any cached
functions/components will show the same content as before the edit.
This is problematic when a function with a `"use cache"` directive is
edited. In this case, the edits won't be applied, and stale content is
shown in the browser, until the dev server is restarted.
With this PR, we are now including an HMR refresh hash in the cache key
for all `"use cache"` functions. This ensures that those functions are
revalidated when a server component is edited, which avoids showing
stale content.
However, while the `"use cache"` functions are revalidated during the
HMR refresh, we will still restore any fetches inside of `"use cache"`
from the [server components HMR
cache](https://nextjs.org/docs/app/api-reference/config/next-config-js/serverComponentsHmrCache)
(unless their input changed because of the edit).
For Webpack, a real content hash is used, which means that if an edit is
reverted to a prior edit, the previously cached data will be retrieved
from the cache. For Turbopack, the HMR hash is currently just an
incrementing counter, which may be improved in a follow-up PR.
closes NAR-65
### What
When there's a async client component used in the component tree, it's not available to display the component stack whether you enable react owner stack or not. It's likely a bug in `React.captureOwnerStack`.
We update the existing test here to ensure the error is surfaced when the mistake is comitted. We also assert on the snapshots of component stack but leave it as a TODO now since the component stack of errored component (the async client component) is not displayed.
Related to NDX-475
LayoutRouter has changed significantly since it was originally written
and the structure has become harder to follow. One thing I always find
confusing whenever I'm reading this code is that some of the values
correspond the the *parent* segment, while others correspond to the
*current* segment. So this moves the code around a bit and updates the
names so it's clearer which parts belong to which segments.
While working on this, I noticed a funny thing about how loading
boundaries work that was made more obvious by the revised naming. I've
left a TODO comment to follow up on whether this was intentional.
This PR improves error handling when `dynamicIO` is enabled.
- prevents well-known errors from being logged
- avoids unhandled rejections being logged during prerendering in dev
mode
- avoids hanging responses when well-known or unexpected errors are
thrown
- ensures pages with `notFound` used in the top level can be prerendered
statically
addresses
https://github.com/vercel/next.js/pull/73210#issuecomment-2515179765
closes NAR-48
- rename `unstable_after` -> `after`
- remove `experimental.after` flag (and warn if it's present)
i separated the big find-and-replace into a separate commit so that it's
easier to see what else changed apart from that.
does not touch docs, that's in #73038
`after` was too restrictive with `draftMode` -- we generally allow reading `draftMode().isEnabled` anywhere. this is because it isn't really a dynamic API -- it's fine to call it in prerender/'use cache' contexts, because we can just prerender/cache it as `isEnabled = false`, and when it's on, it switches everything to dynamic rendering anyway, so that prerender/cache entry is ignored.
However we disallow `draftMode().enable()/disable()` in `after`, because those methods set a cookie, and `after` executes too late for that.
*(Nothing here will change in the upcoming `after` behavior update -- we fundamentally can't get more permissive than this)*