### Why?
To customize Image Optimation, the user can use a custom loader, but
that information was out from the related lint error message.
Closes NDX-181
A multi-zone Next.js app might have complex rewrites for its client
assets. For these apps, resolving a source map through the
`/__nextjs_source-map` dev middleware might fail because the asset might
belong to a different app.
Instead of trying to resolve those rewrites (i.e. using `fetch` instead
of `fs`), we can just bypass the source map dev middleware for client
chunks. Because we control how those source maps are generated, we can
safely assume that the `sourceMappingURL` is relative to the filename,
with an added `.map` extension. The browser can just request this file,
and it gets served through the normal dev server, without the need to
route this through the source map dev middleware.
reverts #72258
This adds `expireTag()` and `expirePath` APIs which are replacing
`revalidateTag` and `revalidatePath`. As such this also marks
`revalidatePath` and `revalidateTag` as deprecated and marked for
removal.
The arguments passed to these methods match `revalidateTag` and
`revalidatePath` with the exception that `expireTag` can receive
multiple tags now as separate arguments which matches our new
`unstable_cacheTag()` API.
We are wanting to update these APIs as `revalidateTag` naming has caused
some confusion as to when the affected items will be updated. The
underlying behavior of `expireTag` is to mark an entry as out of date
and for it to no longer be used so we are expiring it.
If you call `expirePath('/blog/first'`) the next time that item is
requested it is considered expired so the cache will not be used for it
and a fresh entry will be generated. Similarly for `expireTag('posts',
'blog')` the next time any cache with that tag is requested it's
respective cache will not be leveraged and new cache will be populated.
---------
Co-authored-by: Zack Tanner <[email protected]>
Co-authored-by: Delba de Oliveira <[email protected]>
We will wait the server to respond with a compile success message after
a file is patched before proceeding to the next steps in the test to
reduce flakiness.
By doing so, we uncovered a few tests that were passing accidentally due
to flakiness of `patchFile`, and fixed them in the PR.
When using Turbopack, and importing a server action into a client
component, the source map for the client chunk will be requested if
devtools are open. The filename for this source map request might be
`/_next/static/chunks/[project]__800ed2._.js`, for example. This
scenario was already handled by the dev middleware.
However, it didn't consider that there might also be an `assetPrefix`
defined in the `next.config.js`. In this case, the filename would be
`/some-asset-prefix/_next/static/chunks/[project]__800ed2._.js`. When
resolving the external source map for this file, we need to strip the
asset prefix.
Again, this can only be tested manually.
Running the tests continuously for an hour on my PC, the tests succeeded
with no failure.
```
while pnpm test-dev-turbo test/development/app-hmr/hmr.test.ts; do :; done
```
Will monitor the flakiness after this lands. Hope it reduces it below
20%.
After adding validation that fixing invalid segment configs (when DIO is
enabled), it revealed that errors weren't being displayed in Turbopack,
because `setHMRServerError` wasn't implemented.
This refactors the implementation to use the existing server component
transform when validating if the segments are valid. This has the
benefit of highlighting precisely where the segment is coming, making it
easier to remove. The test that was skipped in Turbopack is also
re-enabled.
<details>
<summary>Screenshot</summary>
</details>
This enables DevTools (e.g. Chrome debugger) to collapse stackframes from 3rd party dependencies.
Webpack only. Turbopack added support in https://github.com/vercel/next.js/pull/71770. Replays from RSC will follow.
Had to fork `EvalSourceMapDevToolPlugin` (with blessing from @sokra) to be able to inject `ignoreList`.
For `source-map`, we can use https://github.com/mondaychen/devtools-ignore-webpack-plugin/ instead since we can operate on the assets on disk. I inlined it to iterate on it faster. Though it'd be faster for bundling to also fork `SourceMapDevToolPlugin` since `DevToolsIgnorePlugin` adds another parse/serialize roundtrip.
## test plan
We'll start leveraging `ignoreList` in the terminal as well which will allow us to write automated tests. I haven't found a way to automatically test this ignore-listing in browsers.
Note that this is on Chrome Beta. Chrome Stable does not ignore-list logged stacks yet. Only stacks of the actual `console` call or in the debugger.
(the frame from our console instrumentation is a bug that may be fixed once we populate our own sourcemaps)
`pnpm debug dev test/e2e/app-dir/server-source-maps/fixtures/default/`
`/ssr-error-log` shows
browser:
Node.js debugger doesn't seem to work. Will look at that in a follow-up
We already create server source maps in dev by default,
so we should make use of them.
To opt-out, run `next dev --disable-source-maps` instead.
Our internal `next-no-sourcemaps` script is now defunct.
Updates the heuristic to scoping prerender caches during dev. A cache
scope will be created for every request if one does not already exist.
If the request is a server action we create a new one. existing caches
already expire after 30 seconds (unchanged)
This updates the prefetch cache purge to be 5 seconds since so we don't
mask short lifetime caches
This also adds cache tracking to the first RSC render of the validation
render. This means we now need to always do a second render regardless
of whether there is a sync abort.
Since `console.error` is intercepted, this can be frustrating when a 3p
library that hasn't updated to use the async APIs triggers a warning.
This keeps the error behavior when `dynamicIO` is enabled and warns in
other cases.
Changes `--turbo` -> `--turbopack` to avoid confusion.
- Updated docs
- Updates create-next-app -- For create-next-app it's a rename as
otherwise there is an ordering problem with the prompts
- For the CLI `next dev --turbo` is still supported, will eventually be
a warning in a future version to swap with `--turbopack` but is not a
requirement today, can be handled automatically by the upgrade codemod
- New CLI flag: `next dev --turbopack`
<!-- 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: Will Binns-Smith <[email protected]>
Our patched `console.error` tries to skip internal router errors by
checking `isNextRouterError(error)`. however, if one of those happened
on the server and got replayed on the client, it gets logged differently
-- it's prefixed with the `[ Server ]` badge. this changes the position
where the actual error object is in `args` and thus messes up our
detection, so we end up printing it out (instead of hiding it like we
should)
This PR adds a check that attempts to match replayed server errors
(following [similar logic from react
devtools](https://github.com/facebook/react/blob/65a56d0e99261481c721334a3ec4561d173594cd/packages/react-devtools-shared/src/backend/flight/renderer.js#L88-L93))
and thus also filter out router errors that originated on the server
Closes#71555
This applies similar handling from #71567 to show dynamic IO errors
during client navigations. This also adds a redbox test case for the
initial SSR render.
Previously our rules for allowed dynamic were only enforced in builds.
This is not tenable for serious adoption because you can't spend all day
working on your site and then find out its broken when you build /
deploy.
To address this I've added a simulated prerendering during dev that
should enforce the same rules for rendered routes in dev that would
apply during a build. There is no way to avoid doing additional work to
implement this feature because we need the abort mechanism of SSR to
actually find the dynamic holes that should be disallowed. I was able to
avoid completely duplicating the RSC render however by capturing the
stream chunks available before the first task completes and stashing
them away as a simulated halted RSC payload.
I did have to introduce prospective renders to the RSC render and the
validating SSR render however to work around issues of lazy module
initialization where functions like Math.random and new Date() in module
scope would incorrectly trigger dynamic validation when you would not
expect them to.
This PR adjusts the server action transforms to assign proper function names for the generated server reference proxies.
- If the original function has a name, this name is used.
- If a function expression is assigned to a variable, the variable's name is used.
- If an anonymous function expression is assigned to a prop, the prop's name is used.
In addition, this PR simplifies the output for exported functions, avoiding unnecessary `registerServerReference` calls.
It also fixes the source mapping of default exported server actions.
**Before:**
<img width="890" alt="before" src="https://github.com/user-attachments/assets/a3d6a5f8-d48e-474d-8f03-b49306fb704f">
**After:**
<img width="890" alt="after" src="https://github.com/user-attachments/assets/8f332690-6c26-46f1-9eef-7680f47ea578">
Next up, we will do the same for `'use cache'` functions.
Temporarily removing the dev warnings. I've moved these to be errors in
the build side. In a follow up PR I will use prerendering during dev to
trigger these errors and report them as dev errors as well.
This also updates how we track sync dynamic errors. The main goal is to
have a stack trace of the sync function and separately report all the
component stacks that might contain this function call. It's not
fool-proof b/c the sync api may be called in a way that is not observed
by SSR. The whole debugging story here will improve dramatically with
owner stacks but that is currently experimental only in React.
The plan for future updates is to add a prospective render for SSR so we
can flush out module scope issues like calling Math.random while lazy
initializing a module. This is asserted for RSC in this change (see new
tests) but won't wouldn't pass for SSR b/c we only do single pass
prerendering at the moment.
After that I will add in the prerender-while-render in dev and utilize
the prerender errors to power dev as well.
