Requires vercel/turbo#6388
This uses the structure implemented in vercel/turbo#6388 to support formatted text when reporting. Right now only the `Line` and basic `String` cases are handled.
### What?
Adding a `performance.mark` for next/third-parties for feature measurement
### Why?
We’re working with the Chrome Speed Metrics team to develop an API to better identify specific features used by frameworks and/or CMS platforms. Instead of a entirely new API surface, we've agreed to use `performance.mark` as the signal along with mark_use_counter as a signature.
In the past, we've used HTML attributes for Next which have been helpful, but this will improve the accuracy of our feature detection. In this instance, this will better help us analyze and compare sites that use `@next/third-parties` versus those that don't, and to see if our efforts are actually improving performance.
It's worth noting that this metric will have a public arm, but we're starting to incorporate its usage now to gather early data. performance.mark calls are indeed low-overhead and shouldn't affect loading/rendering performance whatsoever.
### What?
This stops Turbopack from erroring out when trying to parse apps using NextConfig's legacy `experimental.serverActions` boolean value.
### Why?
Old apps may not have removed the legacy boolean flag, but should still run.
### How?
At first I attempted updating Zod's configuration to use a default option config when a boolean was encountered, and passing the updated config to Turbopack, but this would hide the warning message. Then I tried implementing a custom `Deserializer` on the Rust side to handle boolean values and default. But, it was just so much easier to implement with a enum supporting both the current and the legacy configuration.
Closes PACK-1962
### What?
When `FetchCache` is used, cache gets were incorrectly bailing. This would result in unexpected behavior, like continuously revalidating a cache key, as described in #57978.
### Why?
#57902 introduced a refactor to the `FileSystemCache` and changed the interface of `get`, but this change was not propagated to `FetchCache`. Specifically, `fetchCache` was removed in favor of a new type `kindHint`. As a result, cache reads would always short circuit because `fetchCache` would never be defined.
### How?
This updates the interface on `FetchCache` to match what is defined on the base `CacheHandler`. I've also updated the args to both `get` and `set` to be derived from `CacheHandler` so we don't have any type inconsistencies in the future.
I will be following up with a test in the CLI repo to test against a deployed app (since minimalMode cannot be easily mocked in our test suite). Manually verified these changes against the repro in the original issue below, at the following URLs:
https://revalidate-vercel-test-iota.vercel.app/fetch-cache-testhttps://revalidate-vercel-test-iota.vercel.app/revalidate-tag-testFixes#57978Fixes#58306
Previously, the incremental cache returned objects with a readable stream (that were consumed). These can't be shared. Instead, this modifies the cache to instead return strings which are sharable.
This also fixes a bug related to revalidation when writing an updated prefetch RSC payload to the filesystem when PPR is enabled. Previously it just wrote to `.rsc` and now it correctly writes a `.prefetch.rsc` file instead.
## Description
Between 14.0.2-canary.6 and 14.0.2-canary.7, a change was introduced in vercel/next.js#56497 that turned the Redux store state into a Promise, rather than a synchronous state update.
This caused the `sync` function -- used to send state updates to the Redux Devtools -- to be recreated on every dispatch, which in turn, by referential instability, caused the `HistoryUpdater` component to re-render and trigger a `history.replaceState` with no particular change, but with the internal `canonicalUrl`.
When an app does a soft/shallow navigation by calling history methods directly (currently the only way to do shallow search params updates in the app router), these changes would have been overwritten by any prefetch (eg: hovering or mounting a Link), which is usually a no-op for the navigation state.
This PR changes the `sync` function to take the state as an argument rather than as a closure. The whole app router state is also unwrapped only once, and fed to the HistoryUpdater. Changes to its contents made by reducers will cause the HistoryUpdater effect to re-run, triggering history updates and a call to the sync function.
## Context
I maintain [`next-usequerystate`](https://github.com/47ng/next-usequerystate), which is used in the Vercel dashboard, and which is impacted by this change (see
[#388](https://github.com/47ng/next-usequerystate/issues/388)).
## History
@timneutkens introduced the `sync` function and the whole Redux devtools reducer in vercel/next.js#39866, with the note:
> a new hook useReducerWithReduxDevtools has been added, we'll probably want to put this behind a compile-time flag when the new router is marked stable but until then it's useful to have it enabled by default (only
when you have Redux Devtools installed ofcourse).
If a different direction is needed to keep sending `RENDER_SYNC` actions to Redux devtools, I'll be happy to rework this PR to move the `sync` function into the action queue.
## Changes
- [x] Added e2e test. Requires a `start` mode as prefetch links are disabled in development. Test was verified to fail from next@>=12.0.2-canary.7 without the fix.
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
<!-- 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?
-->
This PR fixes a bug where the expected catch-all route would not match
if there were multiple "catch-all routes" under the "parallel route”.
The page on the non-parallel routes path matches the catch all routes.
that exist on the more detailed path.
However, under parallel routes, it matches the most parent page of all
the pages with catch all routes.
For example, if there are files like below:
```
app/@sidebar/[...catchall]/page.tsx
app/@sidebar/dashboard/[...catchall]/page.tsx
```
When accessing `/foo`, it should match
`app/@sidebar/[...catchall]/page.tsx`, and this is working correctly.
However, when accessing `/dashboard/foo`, it should match
`app/@sidebar/dashboard/[...catchall]/page.tsx`, but
`app/@sidebar/[...catchall]/page.tsx` is being matched instead.
## Repository to reproduce
https://github.com/nonoakij/fix-parallel-routes-with-catch-all
## Related PR
https://github.com/vercel/next.js/pull/58215
---------
Co-authored-by: Jimmy Lai <laijimmy0@gmail.com>
## What?
This PR introduces support for manually calling `history.pushState` and `history.replaceState`.
It's currently under an experimental flag:
```js
/**
* @type {import('next').NextConfig}
*/
const nextConfig = {
experimental: {
windowHistorySupport: true,
},
}
module.exports = nextConfig
```
Going forward I'll refer to `history.pushState` as `replaceState` is interchangable.
When the flag is enabled you're able to call the web platform `history.pushState` in the usual way:
```js
const data = {
foo: 'bar'
}
const url = '/my-new-url?search=tim'
window.history.pushState(data, '', url)
```
Let's start by explaining what would happen without the flag:
When a new history entry is pushed outside of the Next.js router any back navigation to that history entry will cause a browser reload as it can no longer be used by Next.js as the required metadata for the router is missing. In practice this makes it so that pushState/replaceState is not feasible to be used. Any pathname / searchParams added can't be observed by `usePathname` / `useSearchParams` either.
With the flag enabled the pushState/replaceState calls are instrumented and is synced into the Next.js router. This way the Next.js router's internal metadata is preserved, making back navigations apply still, and pathname / searchParams is synced as well, making sure that you can observe it using `usePathname` and `useSearchParams`.
## How?
- Added a new experimental flag `windowHistorySupport`
- Instruments `history.pushState` and `history.replaceState`
- Triggers the same action as popstate (ACTION_RESTORE) to sync the provided url (if provided) into the Next.js router
- Copies the Next.js values kept in history.state so that they are not lost
- Calls the original pushState/replaceState
~~Something to figure out is how we handle additional pushes/replaces in Next.js as that should override the history state that was previously set.~~
Went with this after discussing with @sebmarkbage:
- When you open a page it preserves the custom history state
- This is to solve this case: when you manually `window.history.pushState` / `window.history.replaceState` and then do an mpa navigation (i.e. `<a>` or `window.location.href`) and the navigate backwards the custom history state is preserved
- When you navigate back and forward (popstate) it preserves the custom history state
- When you navigate client-side (i.e. `router.push()` / `<Link>`) the custom history state is not preserved
Currently, when a webpack compilation warning is processed by
`WellKnownErrorsPlugin` and it's indeed a well know error that should be
bypassed, the warning item is simply deleted from the array, which will
produce an array with empty items:
Example:
```js
{
client: {
loading: false,
totalModulesCount: 2172,
errors: null,
warnings: [ <1 empty item> ]
},
server: {
loading: false,
totalModulesCount: 2119,
errors: null,
warnings: [ <1 empty item> ]
},
edgeServer: {
loading: false,
totalModulesCount: 58,
errors: null,
warnings: null
},
trigger: undefined,
amp: {}
}
```
This array with empty items generates a side effect on the [build
output](3553c6516d/packages/next/src/build/output/store.ts (L124)),
since the `warning` array has empty items:
```
➤ npm run dev
> next dev
▲ Next.js 14.0.1-canary.3
- Local: http://localhost:3000
- Environments: .env.development
✓ Ready in 2.6s
✓ Compiled /middleware in 109ms (58 modules)
○ Compiling /(dashboard)/page ...
⚠
⚠
```
![CleanShot 2023-10-30 at 13 20
42@2x](https://github.com/vercel/next.js/assets/33168/fd25bc72-61d6-4446-83cb-87768d5135dd)
This PR solves this issue by removing the `warning` item using the
`Array.prototype.splice`, which removes the item instead of making the
array position empty.
Related PR: https://github.com/vercel/next.js/pull/57073
---------
Co-authored-by: Jimmy Lai <laijimmy0@gmail.com>
## Issue
The `context.getFilename()` gets the absolute path of the files, and the if statement to filter `/src` and `/app` was not working since #46609.
## Expected
Do not show a lint warning if use `beforeInteractive` inside `appDir`.
Fixes#46609#50261
Next.js's implementation includes a custom Thenable type based on a
similar one used in React's codebase. It was used to implement a
userspace equivalent of the React.use API before that API became stable,
by throwing a promise-like object and tracking the status on an expando
field. However, it didn't cover all the same cases and behaviors that
React.use does, which led to some subtle bugs like the one fixed by
@ztanner in https://github.com/vercel/next.js/pull/55690.
Now that React.use is stable, and we use that for suspending instead of
throwing a promise, we no longer need our custom Thenable type. I've
removed the type and associated functions, and updated our types to use
Promise instead.
Even in cases where a function does return a thenable-object rather than
a native promise, like React Flight's createFromFetch, we should use
TypeScript's built-in PromiseLike utility. Currently, though, we always
await these objects anyway (in fetch-server-response.ts), which turns
them into promises. So Promise is almost always sufficient.
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This PR fixes a bug where parallel routes would not apply appropriately on navigation when used within slots.
The following scenarios:
```
/foo
/bar
/@slot
/[...catchAll]
```
or
```
/foo
/[...catchAll]
/@slot
/bar
```
will now function correctly when accessing /foo/bar, and Next.js will render both /bar and the catchall slots.
The issue was that the tree constructed by `next-app-loader` for a given path, /foo/bar in the example, would not include the paths for the catch-all files at build time. The routing was done 1-1 when compiling files, where a path would only match one file, with parallel routes, a path could hit a defined path but also a catch all route at the same time in a different slot.
The fix consists of adding another normalisation layer that will look for all catch-all in `appPaths` and iterate over the other paths and add the relevant information when needed.
The tricky part was making sure that we only included the relevant paths to the loader: we don't want to overwrite a slot with a catch all if there's already a more specific subpath in that slot, i.e. if there's /foo/@slot/bar/page.js, no need to inject /foo/@slot/bar/[...catchAll].
One thing that is not supported right now is optional catch all routes, will add later.
fixes#48719fixes#49662
### What
Apply correct url rewrite behavior in the specific context (pages/api).
This won't change anything yet, but it will prevent breaking changes when turbopack makes future changes.
Instead of requiring React in `maybePostpone` (which is susceptible to referencing the wrong version of React during build time, such as in the case where the static worker patches fetch within an app-route, which doesn't have an experimental runtime), this provides the postpone API to the `staticGenerationStore`. That way we know the API is available in render which is when we'd expect to postpone.
The "postpone" terminology is internal to React and can be used for more
things than just this. It's also a mechanism we may or may not rely on.
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
Fixes a broken link, shortens the title, and adds another possible way
to resolve the error.
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This PR fixes the bug in which interception routes of the form `(.)[param]` would not intercept navigations.
The bug happened because we would not create a dynamic route matcher for the intercepted route, so we would never match the correct dynamic route when hitting the server, falling back to the base one.
The fix consists of fixing the logic that checks for a dynamic route so that it checks the correct path when handling an interception route.
There's probably a better fix here, advice welcome
fixes#52533