### What
Only call error log in SSR renderer, instead of calling it in all RSC
and SSR renderers.
Fixes#67352
Close NEXT-3579
### Why
The RSC rendered generated result will be rendered by SSR renderer
again, at there we can get the actual error. So when there's a RSC error
happening, only logging once in SSR rendering layer is enough.
### What?
This disallows merging of global css with styles that appear on other
pages/chunk groups.
### Why?
Before we made the assumption that all CSS is written in a way that it
only affects the elements it should really affect.
In general writing CSS in that way is recommended. In App Router styles
are only added and never removed. This means when a user uses
client-side navigations to navigate the application, styles from all
previous pages are still active on the current page. To avoid visual
artefacts one need to write CSS in a way that it only affects certain
elements. Usually this can be archived by using class names. CSS Modules
even enforce this recommendation.
Assuming that all styles are written this way allows to optimize CSS
loading as request count can be reduced when (small) styles are merged
together.
But turns out that some applications are written differently. They use
global styles that are not scoped to a class name (e. g. to `body`
directly instead) and use them in different sections of the application.
They are structured in a way that doesn't allow client-side navigations
between these sections. This should be valid too, which makes our
assumption not always holding true.
This PR changes the algorithm so we only make that assumption for CSS
Modules, but not for global CSS. While this affects the ability to
optimize, applications usually do not use too much global CSS files, so
that can be accepted.
fixes#64773
### What
When using `generateStaticParams` with interception routes, the
interception would never occur, and instead an MPA navigation would take
place to the targeted link.
### Why
For interception rewrites, we use a `__NEXT_EMPTY_PARAM__` marker (in
place of the actual param slot, eg `:locale`) for any params that are
discovered prior to the interception marker. This is because during
route resolution, the `params` for the interception route might not
contain the same `params` for the page that triggered the interception.
The dynamic params are then extracted from `FlightRouterState` at render
time. However, when `generateStaticParams` is present, the
`FlightRouterState` header is stripped from the request, so it isn't
able to extract the dynamic params and so the router thinks the new tree
is a new root layout, hence the MPA navigation.
### How
This removes the `__NEXT_EMPTY_PARAM__` hack and several spots where we
were forcing interception routes to be dynamic as a workaround to the
above bug. Now when resolving the route, if the request was to an
interception route, we extract the dynamic params from the request
before constructing the final rewritten URL. This will ensure that the
params from the "current" route are available in addition to the params
from the interception route without needing to defer until render.
Fixes#65192Fixes#52880
### What
When PPR is off, app router prefetches will render the component tree up
until it encounters a `loading` segment, at which point it'll just
return some metadata about the segment and won't do any further
rendering. This is an optimization to ensure prefetches are lightweight
and don't potentially invoke expensive dynamic subtrees. However,
there's a bug in this logic that is causing it to bail unexpectedly if a
segment deeper in the tree contained a `loading.js` file.
This would mean the loading state wouldn't be triggered until the second
request for the full RSC data is initiated, resulting in an unintended
delta between when a link is clicked and the loading state is shown.
### Why
The `shouldSkipComponentTree` flag was incorrectly being set to `true`
even if the `loading.js` segment appeared deeper in the tree. Prefetch
requests from the client will always contain `FlightRouterState`, so the
logic to check for loading deeper in the tree will always be missed.
### How
This removes the `flightRouterState` check as it doesn't make sense:
prefetches will currently _always_ include the `flightRouterState`,
causing this to always short-circuit. I believe that this check is
vestigial from when we were generating static `prefetch.rsc` outputs
which is no longer the case.
This mirrors a [similar
check](b87d8fc499/packages/next/src/server/app-render/create-component-tree.tsx (L393))
when determining if parallel route(s) should be rendered.
This leverages [fetch
priority](https://developer.mozilla.org/en-US/docs/Web/API/Request/Request#priority)
to ensure automatic prefetching as a result of visiting a page is sent
with "low" priority, to signal to the browser it can prioritize more
important work necessary for rendering the page.
A "temporary" prefetch (ie one that is created when there wasn't an
existing prefetch cache entry on navigation) will use a "high" priority
because it's critical to the navigation event.
All other cases will be "auto" which is the current default.
When a server action responds with something other than an RSC response,
we currently silently ignore the error and it doesn't get propagated to
any rejection handlers.
This adjusts the handling so that if the server action response is a
non-successful status code, we reject the server action promise. If the
error is `text/plain`, we'll automatically propagate the text content as
the error text. Otherwise, the promise is rejected with a fallback
message.
Fixes some possible race conditions by adding a few delays to the
navigation test to ensure that we wait for hydration to occur and
prefetches to finish.
### What
Reland #64716
Removing the Suspense boundary on top of `next/dynamic` by default, make
it as `React.lazy` component with preloading CSS feature.
* Remove `suspense` option in `next/dynamic` since it's already
deprecated for a while
* Remove the default loading in app router implmentation of
`next/dynamic`
### Why
Extra Suspense boundary is causing extra useless rendering. For SSR, it
shouldn't render `loading` by default
Related: #64060
Related: #64687
Closes
[NEXT-3074](https://linear.app/vercel/issue/NEXT-3074/app-router-content-flickering-with-reactcreatecontext-and-nextdynamic)
This is sort of a breaking change, since removing the Suspense boundary
on top of `next/dynamic` by default. If there's error happening in side
the dynamic component you need to wrap an extra Suspense boundary on top
of it
### What
Add isEdgeRendering check condition for rewrite logic in edge adpator
Fixes#66837
Closes NEXT-3545
### Why
From headers `x-middleware-rewrite`, it's still relative url `/rewrite`,
reconstructing the url will lead to crash as it doesn't contain host.
### What
Render noindex into a flight data and rsc payload when page path is
`/404`
### Why
When it's static generation, noindex is not rendered due to the
statusCode from mock request is 200, but we can relying on the pagePath
as `/404` page should always contain `nonidex`
We were missing the noindex before for flight generation, now we'll
render it when it's 404 page.
When accessing search params, we only track dynamic access during static
generation. This has implications on fetch caching, because the fetch
cache relies on hints set during render that it's in a dynamic scope. In
15, this would signal that it should not attempt to cache the fetch at
all. In 14, this could impact the heuristic that bails from fetch cache
if dynamic access came before certain requests types, e.g. POSTs.
...with `assertHasRedbox` and `assertNoRedbox`.
`hasRedbox()` has a hardcoded timeout of 5s that is only required for
the negative assertion.
Instead, we now have dedicated assertions for the positive
(`assertHasRedbox`) and negative case (`assertNoRedbox`).
The negative assertion still has the hardcoded timeout.
But the positive assertion just retries until we find the Redbox.
This speeds up tests using the positive assertion.
Removing `hasRedbox` also uncovered some unused expressions e.g. `await
hasRedbox(browser)`.
These expressions probably wanted to use `expect(await
hasRedbox(browser)).toBe(true)
## What?
This PR adds an option to use `sass-embedded`.
## Why?
For large projects sass-embedded improves SCSS compilation time by over
50%.
See also https://github.com/vercel/next.js/discussions/36160
## How?
Added a sassOption `implementation` to configure the sass-loader which
Sass implementation to use.
See also https://www.npmjs.com/package/sass-loader#implementation
I think this a similar approach to what is done for `additionalData`.
## Additional notes
In order to support `sass-embedded`, `sass-loader` is upgraded to
12.6.0.
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
### What?
Writes the async flag to the client reference manifest to support ESM
externals in app dir.
The `app-ssr` context can't have esm externals as that might cause a
module to be async in ssr but not on the client.
Closes PACK-2967
Fixes#64525
### What
app-dir `metadata.test.ts` is pretty big and includes a lot of erroring
tests and navigation tests. Breaking them into smaller suites to avoid
the erroring on effect on others.
- metadata
- metadata-navigation
- metadata-thrown
Moved the metadata testing utils into `next-test-utils` for sharing
purpose.
Moved the hmr test to the bottom to avoid flakyness.
When performing a redirect() with an absolute path, action-handler
attempts to detect whether the resource is hosted by NextJS. If we
believe it is, we then attempt to stream it.
Previously we were not accounting for basePath which caused absolute
redirects to resources on the same host, but not underneath the
basePath, to be resolved by NextJS. Since the resource is outside the
basePath we resolve a 404 page which returns back as `text/x-component`
and is thus streamed back to the client within the original POST
request.
This PR adds a check for the presence of the basePath within absolute
redirect URLs. This fixes the above problem.
fixes#64413fixes#64557
---------
Signed-off-by: Chris Frank <chris@cfrank.org>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This handles the case where a middleware rewrite causes us to fail to
resolve the correct dynamic route params for an action sent to a
prerendered ISR path since the matched path wouldn't be the original
source path like we expect and instead is the prerendered path so we
need to parse the params out instead.
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
Users that experiment with PPR and might have seen #61798, or #62703, or
most recently #65483, may try the `__nextppronly=1` query param to debug
the static shell. This will lead to the following uncaught error and
blank page:
<img width="1045" alt="static shell debugging hydration error"
src="https://github.com/vercel/next.js/assets/761683/ed382d97-82ae-4a23-9930-bb4d4419e88e">
It might not be immediately obvious that javascript must be disabled to
see the static shell. To improve the DX in this scenario we can omit the
bootstrap script to skip hydration, and thus prevent the error. Then
debugging the static shell works even without disabling javascript in
the devtools.
<img width="1045" alt="static shell debugging without hydration"
src="https://github.com/vercel/next.js/assets/761683/57f6cb88-f5b4-473f-963f-7fda8c8e7f00">
In addition, we should add the closing body and html tags to the shell
so that a valid HTML document is returned.
`node_modules` gets ignored when deployed unless explicitly allowed, and
the regular install command will clobber what was in there.
This allowlists the `node_modules` directory and copies it into a new
folder, runs the install command, and then merges the patched
`node_modules` in so the patched modules are available in the test.
Only 1 test suite in this suite is failing and it's related to file
tracing, which should be fixed in a follow-up. For now this enables
deploy tests for everything else to make sure we don't regress.
This also simplifies the original test to not require stopping the
server & patching a file.
- Fixed redirects tests not working when deployed because they were
`POST` requests to a static page
- Skipped 404 test for a similar reason: a `POST` to the static not
found page is handled differently, and we won't have access to the
runtime logs anyway
- Refactored interception routes test to not rely on runtime logs
- Fixed revalidation test & removed comment about flakiness
<details>
<summary>Validated Run Summary</summary>
</details>
These 2 tests use an in-memory data store that won't be necessarily
shared across invocations of the lambda. This skips the tests that rely
on that functionality as testing it in `next start` should be
sufficient.
This test was only failing because `vercel logs` limit the output to 100
lines, and telemetry debugging was adding a lot of verbosity to the
build logs.
This bumps the log lines to a higher value to give some more breathing
room, and did a drive-by `check` -> `retry` refactor.
This disables tests that should not be run in a deployed environment,
because they use incompatible APIs or there's no reason to test them
outside of `next start`. Specifically disables for things like:
- Using `next.patchFile`, `next.renameFile`, etc.
- Attempting to use `next.cliOutput` to query runtime logs. When
deployed, these are only build-time logs.
[Latest Run](https://github.com/vercel/next.js/actions/runs/9483807368)
- `next.cliOutput` will only refer to build time logs, so this
particular assertion won't work
- Drive-by refactor for it to use `retry` instead of `check`
Verified this passes when deployed
Closes [#66650](https://github.com/vercel/next.js/issues/66650)
Closes NEXT-3520
### What?
- Make Link not throw during prefetch if it received an invalid `href`
(see [#66650](https://github.com/vercel/next.js/issues/66650))
- Throw in dev mode if an invalid link was passed to `router.prefetch`
-- this matches current prod behavior
- (previously, we'd immediately exit out of `router.prefetch`, so the
user would see no indication that this'd fail in prod)
### Why?
If an invalid URL was passed to `<Link>`, the whole app would crash and
show "A client-side exception occurred". A failed prefetch should not
bring down the whole app.
Note that This preserves the current behavior of explicit
`router.prefetch(url)` throwing an error if `url` is invalid. We may
want to adjust this in the future, but that could be considered a
breaking change, so I'm leaving it out for now. This only affects
`Link`, which was intended to catch any errors thrown from
`router.prefetch`, but that bit was accidentally broken.
### What
Add new test case where a named export from client component is being
exported as page
### Why
We found this case while investigating the errors triggered introduced
by #66286 , adding this test to avoid future regression
To assist with the development and testing of the new partial
prerendering (PPR) paradigm, this introduces a stop-gap solution to let
us verify issues with pages in preview and production environments if
enabled. When a Next.js app is built and ran with the
`__NEXT_EXPERIMENTAL_STATIC_SHELL_DEBUGGING=1` environment variable,
pages that have PPR enabled in production and preview environments can
have only their static shell served when accessed with a
`?__nextppronly=1` query parameter.
If your project is not using PPR, it will not change anything. If a page
is accessed in production or development with the query parameter but
PPR is not enabled, it will not change anything. Tests have been added
to validate that going forward.
### What
Optimizing the static generation for dynamic metadata routes
If you're not using `generateSitemaps()` or `generateSitemaps()`, you
don't need to change any file conventions.
If you're using multi sitemap routes, make sure the returned `id`
properties from `generateSitemaps()` don't need to contain `.xml`, since
we'll always append one for you.
Analyzing the exports of metadata routes and determine if we need to
make them as dynamic routes.
### Why
Previously, users are struggling with the multi routes of sitemap or
images.
For sitemap, the `.xml` extension in url doesn't get appended
consistently to the multi sitemap route between dev and prod.
For image routes, the generated image routes are always dynamic routes
which cannot get static optimized.
The reason is that we need to always generate a catch-all route (such as
`/icon/[[...id]]` to handle both single route case (e.g. without
`generateImageMetadata`, representing url `/icon`) or multi route (e.g.
with `generateImageMetadata`, representing url `/icon/[id]`), only
catch-all routes can do it. This approach fail the static optimization
and make mapping url pretty difficult as parsing the file to check the
module exports has to be done before it.
#### Benifits
For image routes urls, this approach could help on static generation
such as single `/opengraph-image` route can be treated as static, and
then it can get static optimized if possible.
**Before**: `/opengraph-image/[[...id]]` cannot be optimized
**After**: single route `/opengraph-image` and multi-route
`/opengraph-image/[id]` are both possible to be statically optimized
For sitemap, since we removed appending `.xml` for dynamic routes, it’s
hard for users to have `/sitemap.xml` url with dynamic route convention
`sitemap.js` . But users desire smooth migration and flexibility.
**Before**: In v15 rc we removed the `.xml` appending that `sitemap.js`
will generate url `/sitemap` makes users hard to migrate, as users need
to re-submit the new sitemap url.
**After**: Now we'll consistently generate the `.xml`. Single route will
become `/sitemap.xml`, and multi route will become `/sitemap/[id].xml`.
It's still better than v15 as the urls generation is consistent, no
difference between dev and prod.
Here's the url generation comparsion
#### Before
All the routes are dynamic which cannot be optimized, we only had a
hacky optimization for prodution build multi-routes sitemap routes
| | only default export | `export generateImageMetadata()` | `export
generateSitemaps()` |
| -- | -- | -- | -- |
| opengraph-image.js | /opengraph-image/[[...id]] |
/opengraph-image[[...id]]/ | /opengraph-image/[[...id]] |
| sitemap.js | /sitemap/[[...id]] | /sitemap/[[...id]] | dev:
`/sitemap/[[...id]]` prod: `/sitemap/[id]` |
#### After
Most of the single route will are to get statically optimized now, and
the multi-routes sitemap are able to get SSG now
| | only default export | `export generateImageMetadata()` | `export
generateSitemaps()` |
| -- | -- | -- | -- |
| opengraph-image.js | /opengraph-image | /opengraph-image/[id] | - |
| sitemap.js | /sitemap.xml | - | /sitemap/[id].xml |
Next.js will have less overhead of mapping urls, we can easily multiply
the urls generation simply based on file conventions.
x-ref: feedback from #65507Closes#66232
### Why?
Importing `tailwind/tailwind.css` is not possible right now with
turbopack, and there's no reason it needs to be marked as external.
### How?
Closes PACK-3013
Fixes#64837
### What
Keep `test/e2e/app-dir/metadata-dynamic-routes/index.test.ts` with
successful build cases, move the dev error tests into separate test
### Why
x-ref:
https://github.com/vercel/next.js/actions/runs/9429301722/job/25975574075?pr=66286
Before the moving the tests, the error is flaky with turbopack since the
error will fail the hmr. Error observed with turbopack when seeing build
failed cases. So I moved the tests into the separate dev tests, running
inside sandboxes. Then each error test doesn't effect each other.
```
⨯ ./app/metadata-base/unset/icon--metadata.js:1:1
Module not found: Can't resolve './icon.tsx'
> 1 | import { generateImageMetadata } from "./icon.tsx"
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2 | import { fillMetadataSegment } from 'next/dist/lib/metadata/get-metadata-route'
3 |
4 | const imageModule = { generateImageMetadata }
```
### What
Remove creating client proxy for each ESM export, instead for ESM we
create a CJS module proxy for itself and access the property with export
name as the actual export.
### Why
`proxy` is the module proxy that we treat the module as a client
boundary.
For ESM, we access the property of the module proxy directly for each
export.
This is bit hacky that treating using a CJS like module proxy for ESM's
exports,
but this will avoid creating nested proxies for each export. It will be
improved in the future.
Notice that for `next/dynamic`, if you're doing a dynamic import of
client component in server component, and trying to access the named
export directly, it will error. Instead you need to align the dynamic
import resolved value wrapping with a `default:` property (e.g. `{
default: resolved }`) like what `React.lazy` accepted.
Revert #57301Fixes#66212
x-ref:
[slack](https://vercel.slack.com/archives/C04DUD7EB1B/p1716897764858829)
During navigations, the `FlightDataPath` property from the server
response can be an array if there are multiple parallel routes (eg,
`children` and `slot`). When we apply server response to the router
cache, we might call `applyFlightData` for each segment path, which will
copy existing cache values and insert new ones depending on what
changed.
However, the `existingCache` argument that we pass to this function is
the cache at the start of the navigation. That means subsequent calls to
`applyFlightData` will reference the cache _before_ updates are made to
it. This will cause it to erroneously think it needs to lazy fetch for
missing data.
<!-- 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 #
-->
When checking which segment(s) need to be refreshed, we currently
compare the current page URL with the segment's refresh marker.
We should inspect the `mutable.canonicalUrl` value first since that's
the URL we're changing to, followed by `state.canonicalUrl` as a
fallback (indicating that there's no URL change pending). This is
because the server action handler will receive a redirect URL prior to
`location.pathname` being updated, so the router will incorrectly think
it needs to refresh the data for the page we're going to.
Closes NEXT-3500
This flag remained experimental because the IPC implementation didn't
play nicely with requests containing large payloads, due to it being
stringified as GET parameters. This branching logic also poses
challenges for some upcoming work related to detecting IO.
This removes the handling for the
`experimental.staticWorkerRequestDeduping` flag which we can revisit in
the future with a sounder approach. This also cleans up some of the IPC
server utilities as it wasn't in use anywhere else.
<!-- 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 #
-->
### What & Why
Fixes NEXT-3498
Fixed loading shows up and disappear during client navigation, when you
defined `prefetch` is enabled and slow `generateMetadata` is defined. In
#64532, where in layout-router, we removed the place of infinite
suspense, adding it back so that the app can still remain suspensy
during navigation.
#### Behavior before fix
Prefetch -> Link Navigation -> Show `loading.js` -> RSC payload fetched
(no page content) -> the page content will display later when the
promise is resolved
#### Behavior after the fix
Prefetch -> Link Navigation -> Show `loading.js` -> RSC payload fetched
-> suspensy page content still triggering `loading.js` -> display the
resolved page content when the promise is resolved
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
