### 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>
New PR
Update DevDependecies "validate-npm-package-name" and type
PR closed: #66420
---------
Co-authored-by: torresgol10.itd <torresgol10.itd@gmail.com>
Co-authored-by: Sam Ko <sam@vercel.com>
When `router.refresh` or a server action creates a new `CacheNode` tree,
we were erroneously not copying over the `loading` segment in the new
tree. This would cause the subtree to be remounted as the loading
segment switched from having a Suspense boundary to not having one.
Fixes#66029Fixes#66499
This removes the previous `server/future` directory and moves everything
into the `server` or `server/lib` directories. This is aimed to start to
flatten the server application structure.
### What?
optimize allocations in server actions transform
In one edge case it reduces allocations from 30GB to 4.5MB and time from
760ms to 11ms.
### Why?
make it faster
### What?
* order of CSS between layout and page
* order of CSS between page and next/dynamic
### Why?
### How?
* overrides webpack CSS chunk loading to use react CSS loading to allow
them to share the order
This takes the `layerAssets` property from the previous PR and actually
renders it, replacing the previous style handling. This ensures that
when multiple page segments are rendered on screen, all of their
associated CSS files are loaded. The existing `findHeadInCache` method
only ever returns a single head node, which means it’d miss stylesheets.
Fixes#59308Fixes#63465
This adds a new `layerAssets` property (containing styles and script
tags) to `FlightDataPath`. Previously these were lumped in with the
`head` node, but we intentionally only ever render a single `head`, to
avoid duplicating metadata. This would mean `<AppRouter />` would only
ever render imported stylesheets for a single page in a racey way.
However, since Float handles hoisting and deduping these style tags,
we're safe to render them for each segment.
This PR introduces no change in behavior, aside from sending
`layerAssets` down from the server and storing it in the client router
cache. These nodes aren't rendered -- this is done in #66300.
This adds details for every ISR cache request if the page being
requested supports PPR. If it does, it'll attempt to load the
`.prefetch.rsc` payload instead of the `.rsc` payload. This corrects a
bug that was present in deployed environments.
This additionally refactors the `isAppPPREnabled` out of most of the
application, as it's only used to determine if we should add to the
`prefetchDataRoute` fields in the `prerender-manifest.json`. To support
loading the prefetch file or not, we pass the `isRoutePPREnabled`
through with the cache get/set operations instead.
x-slack-ref:
https://vercel.slack.com/archives/C075MSFK9ML/p1717094328986429
### What?
If the error message contains a reference to `node_modules` it would
omit the error message, but actually we only want to omit the stack
frames
### Why?
### How?
### What?
We have a GC with rough edges, but it is worth exposing a flag to be able to try it out.
### Why?
I think it would be useful to set up a benchmark that tests the GC perf on new canary builds to make sure we are going in the right direction.
### How?
Add a new flag in the experimental settings and wire it up to the existing native bindings.
Closes PACK-3093
In #60645, dynamic access tracking was refactored but we erroneously
stopped tracking dynamic access in route handlers. Request proxying, as
well as tracking segment level configs (such as `export const dynamic =
'force-dynamic'`), were only enabled during static generation. This was
an unintended breaking change that consequently caused dynamic access to
not properly bail from data cache in various circumstances.
This adds some more rigorous testing for route handlers, as this seems
to be a fairly large gap in our fetch cache testing currently.
This PR is easiest to review with [whitespace
disabled](https://github.com/vercel/next.js/pull/66446/files?w=1).
### What
Change the metadataBase missing warning for all cases to only warn in
standalone mode or the non-vercel deployment.
### Why
In vercel deployments, previous concern was that you might not discover
you missed that metadataBase when you deploy. But now we have sth
fallback on production deployments. So we only need to warn in
non-vercel deployment.
Standalone is usually for self-hoist, we always warn users to set the
`metadataBase` to make sure the domain can be properly resolved.
[x-ref](https://vercel.slack.com/archives/C03S8ED1DKM/p1716926825853389?thread_ts=1716923373.484329&cid=C03S8ED1DKM)
When the router encounters a `stale` cache entry, it clears the `rsc`
data so that it can be fetched in render. All navigations (even just for
hash fragments) flow through the navigation reducer, which has logic to
discard any existing cache entries when the cache is stale.
This bug has become more obvious after removing the default 30s cache,
which would previously have masked it.
This updates the existing handling that clears flight data to not do so
if only the hash changes as there would be no server changes in this
case.
<!-- 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 #
-->
Transient/recoverable errors can cause page(s) to fail. When building an
app with a lot of static pages, a single page failing to build can be
frustrating, especially if it it'll pass on a retry. This adds an
experimental `staticPageGenerationTimeout` property that can be used to
configure how many times Next.js attempts to build a particular page
before giving up.
I recommend reviewing this PR [without
whitespace](https://github.com/vercel/next.js/pull/66393/files?w=1)
<!-- 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 #
-->
We already have workers available when determining if a page is static,
and we expose those workers to the page export handler. We should re-use
those workers instead of creating new ones.
In practice this seems like dead code, since `setupWorkers` returns the
existing workers if a pages worker exists, and we always create a pages
worker.
<!-- 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?
This bumps the supported `msw` version when using the `playwright` test
mode. There's no need for mocking requests and responses anymore since
[they adopted](https://github.com/mswjs/msw/pull/1436) the global fetch
API in `msw`.
### Why?
Users can extend `test` from `playwright` manually and create the `msw`
fixtures, but it's better if it works out of the box with newer versions
of `msw`.
Fixes#63338.
Co-authored-by: Sam Ko <sam@vercel.com>
Effectively a revert of https://github.com/vercel/next.js/pull/66006,
but:
- Keeps the cleanup changes from that PR.
- With https://github.com/vercel/nextpack/pull/106 removing the explicit
`--features plugin` flag, we will match behavior between cargo's
defaults and the nextpack development scripts (which we want to do for
maximizing cache reuse).
The tradeoff here is faster cold builds, at the cost of waiting longer
when you want to test with plugins.
Feedback from @kdy1 was:
> I think it's a good idea to disable plugin by default for nextpack. We
don't use it for most of daily development, but it's very large and slow
to compile
Tested by running both:
```
pnpm build-native
pnpm build-native-no-plugin
```
This modifies the patched fetch implementation to better handle when
called within an `unstable_cache` callback. In these callbacks, it
should not throw an error related to dynamic access.
This replaces the verbose `trackDynamicFetch` instead with
`markCurrentScopeAsDynamic` which already has support for checking if
inside an unstable cache context. It also has been adjusted to be a
no-op when `export const dynamic = "force-static"`, further simplifying
the code within the patch fetch implementation.
