### What?
Fixes https://github.com/vercel/next.js/issues/50129
### Why?
The current denormalization of app dir paths doesnt account for the
normalization done in `normalizeAppPath`, causing build log outputs for
certain paths such as anything under a route groups to be incorrect
### How?
There's 2 ways this could be fixed:
1.) Denormalize the app dir paths by reading the
`app-path-routes-manifest.json` and mapping back to the original file
path
2.) (what I chose to do) Normalize the keys of `appBuildManifest`
### Result
App dir paths, including route groups, now have their correct output
size
<img width="494" alt="image"
src="https://github.com/vercel/next.js/assets/93682696/0eee79b8-7d60-4c88-b07a-dfb750aa9592">
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Similar to tags and paths, when `cookies().set()` is called we have to
invalidate the client router cache as well so routes with
`cookies().get()` will not holding the stale data. This is critical for
auth and other scenarios.
In the future we can have an optimization to only invalidate routes that
actually rely on cookies, similar to paths.
This PR fixes a few reports that we were double fetching when navigating via a link that had prefetch false.
## Context
The bug was happening because we were inadvertently eagerly fetching even if we potentially bailed out of the optimistic navigation, which would then trigger another fetch from going through the regular navigation path.
There's potentially another bug here where we should potentially not bail out of optimistic navigation in the cases reported but we can fix that later.
fix#49844
link NEXT-1287
## What?
While looking at the CPU profile of booting up Vercel's site I noticed
that we call `getPageStaticInfo` a lot. Looking into this more it turns
out `getPageStaticInfo` is currently called for all routes, `pages` and
`app`, even though the data is only being used to keep track of which
routes are edge functions, however, this is already tracked as part of
the build output so this didn't make sense to me. First I tried
commenting out this entire block and all tests were passing, so I
removed it except for middleware as middleware can provide a `matcher`
which does need to be known before compiling the file as of right now.
After that change a different set of tests started failing, specifically
the one that checks if we warn correctly. Interestingly by fixing
`getPageStaticInfo` being called early and for all routes it also caused
these warnings to no longer trigger as there was a case in the manifest
plugin that called `getPageStaticInfo` with less information. Calling
`getPageStaticInfo` there was not needed either as we call
`getPageStaticInfo` at the beginning of the build for each entrypoint so
we already have the information required, it just had to be passed down
so that the manifest plugin could use it.
For Vercel's site this change improves booting the dev server by over 1
second.
Related to #48748
<!-- 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
- 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: Jiachi Liu <inbox@huozhi.im>
When navigating to a route with a hash parameter, the layout router
jumps to the element by scrolling to the node's `offsetTop` value.
However, this will ignore `scroll-padding`, which deviates from browser
behavior.
It looks like this isn't an issue in the pages router which currently
makes use of
[`scrollIntoView`](https://github.com/vercel/next.js/blob/canary/packages/next/src/shared/lib/router/router.ts#L2262).
Closes NEXT-1171
Fixes#49612
---------
Fixes#50232
Passing down the private env into `'render-server'` module to pick up the proper react with require-hook in standalone server
fix NEXT-1260
Follow up for #50548
There're some packages like `aws-sdk-js-v3` which doesn't have a exports field yet:
```
"main": "./dist-cjs/index.js",
"types": "./dist-types/index.d.ts",
"module": "./dist-es/index.js",
```
This PR let u pick up by the js assets based on main fields, will prefer `"module"` field instead of `"main"`
Closes NEXT-1286
Adding a `_rsc` query for RSC payload requests so that they can be
differentiated on resources level for CDN cache for the ones that didn't
fully respect to VARY header.
Also stripped them for node/edge servers so that they won't show up in
the url
x-ref:
https://github.com/vercel/next.js/pull/49140#issuecomment-1549405009Closes#49140
Closes NEXT-1268
Like how we handled RSC loader transform before, we also apply swc
loader to middleware to make sure the imports optimization is applied so
og package won't be bundled
Fixes#50492
There are some incoming docs / MDX changes where prettier will throw an error when using the older version. Updating prettier before I bring in those changes.
Looks like the most notable change is adding parentheses around `typeof` checks in TypeScript.
**Before**
```
export type Locale = typeof i18n['locales'][number]
```
**After**
```
export type Locale = (typeof i18n)['locales'][number]
```
Encode the state tree where the content could contain unicode when
request the RSC payload, to avoid the fetch failure due to bad encoding
for headers
Fixes#48728
fix NEXT-1258
After enabling Draft Mode, `router.refresh()` was incorrectly causing the page to crash and do a full page refresh.
This PR fixes this case.
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
For RSC server layer so far we bundle all dependencies, ESM format is the better one rather than CJS to analyze and tree-shake out the unused parts. This PR changes pick the condition names that are in ESM format first for server layer.
Also fixes the misorder of condition names of edge runtime, `conditionNames` should only contain either ESM or CJS, previously the main fields are mixed with conditon names which is not expected for webpack, we separate them now.
Since we're picking ESM instead CJS now, the error of require `exports * from` doesn't exist anymore, but if you're using a CJS dependency which require a ESM package, it will error. This is the existing behavior for our webpack configuration but could happen on server layer bundling
Other related changes:
* Imports are hoisted in ESM, so migrate`enhanceGlobals` to a imported module
* Use `...` to pick the proper imports by import expression, and prefer the `react-server` / `edge-light` condition names for corresponding cases
* Remove edge SSR duplicated `middleware` export checking
This makes sure that if `revalidateTag` is called in a Server Action, the client router cache and prefetch cache are invalidated correctly so following navigations won't reuse the cache that might hold stale data.
Similar case for `revalidatePath`. I left a TODO where we can't just invalidate the subtree under the revalidate paths because of current implementation limitations. To ensure correctness, we just do the same as `revalidateTag`.
When twitter metadata is not provided but opengraph metadata is, fill the opengraph basic information for twitter metadata.
Twitter card can't be displayed if there's no information from twitter meta tags, at least the `twitter:card`. We fill the `title` `description` and `images` these 3 overlapped properties from opengraph image so they can be displayed properly
Closes NEXT-1111
## What?
Anytime you open a Next.js application that doesn't have a `favicon.ico`
you'll notice `/_error` is being compiled because the browser requests
`favicon.ico`. This PR ensures the 404 page is not compiled in
development for that request. It helps a little with compilation speed.
<!-- 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 or adding/fixing 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: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Updates to not throw the dynamic server error inside of the patched
fetch as it's typical for fetch errors to be caught and handled and this
error is not meant to be caught by users. This instead throws it during
rendering so we can ensure we catch it instead of users.
x-ref:
https://github.com/vercel/next.js/actions/runs/5182384027/jobs/9339123096
## What?
Recently I've been using these hello-world tests quite often to get the baseline traces out for `pages` and `app`.
Adding them to the repo so that I don't have to recreate / stash them all the time.
This field is no longer needed. Although removing it might cause
unnecessary styles being included that could be tree-shaken potentially,
it solves a more critical issue of missing CSS resources: since now CSS
import can be "hoisted" to its parent entry (e.g. a layout), we can't
simply get all used CSS resources from the "leaf entry" (e.g. a page).
This PR fixes a couple of categories of CSS issues in App Router, that
come from the same root cause.
### 1. Duplicated styles being loaded in different layers
This issue has been described in
https://github.com/vanilla-extract-css/vanilla-extract/issues/1088#issuecomment-1563931144.
If a CSS module (or a global CSS) is referenced in multiple layers (e.g.
a layout and a page), it will be bundled into multiple CSS assets
because each layer is considered as a separate entry.
<img width="1141" alt="CleanShot-2023-05-26-GoB9Rhcs@2x"
src="https://github.com/vercel/next.js/assets/3676859/8e0f5346-ee64-4553-950a-7fb44f769efc">
As explained in that issue, we have to bundle all CSS modules into one
chunk to avoid a big number of requests.
### 2. CSS ordering issues (conflicts)
This is likely causing https://github.com/vercel/next.js/issues/48120.
When the layer-based bundling and ordering logic applies to CSS, it can
potentially cause non-deterministic order. In this example, button A in
the layout should be in blue. However when button B is imported by the
page, button A becomes red. This is an inconsistent experience and can
be hard to debug and fix.
<img width="1090" alt="CleanShot-2023-05-26-Ar4MN5rP@2x"
src="https://github.com/vercel/next.js/assets/3676859/4328d5d7-23af-4c42-bedf-30f8f062d96a">
### What?
This test case was never passing and accidentally enabled for Turbopack.
We could disable the whole test suite, but since only one test case is
affected we can also disable only that one.
## What?
Currently we use the initial compile to add entrypoints that we know are
going to be used in the application. For example the Next.js runtime,
`react`, `react-dom`, and such. While this was the right default when
Next.js only had `pages`, it's no longer true when both `pages` and
`app` exist. E.g. when you're working on a page using App Router we'd
still compile `pages/_app`, `pages/_document`, and `pages/_error` even
though those would not be used. In case of larger applications (e.g.
Vercel's application) this would mean thousands of extra modules being
compiled even though you don't need them for the page you're looking at.
Similarly we'd compile the Next.js runtime for App Router even when
you're only using `pages`.
This PR changes the handling to only compile the entries that are needed
for the current set of visited pages (on-demand-entries). If that set
only includes `app` entrypoints then the `pages` related files will be
excluded. If the set contains both `app` and `pages` both will be
included. Similarly for `amp`, if you don't use `amp: true` / `amp:
hybrid` the development runtime will not be compiled.
📔 Note: This is specifically for webpack, Turbopack already compiles
everything needed lazily so it didn't have this limitation.
#### Before
```
- event compiled client and server successfully in 1079 ms (306 modules)
- event compiled client and server successfully in 155 ms (306 modules)
```
With opening `/`:
```
- event compiled client and server successfully in 1118 ms (306 modules)
- event compiled client and server successfully in 157 ms (306 modules)
- event compiled client and server successfully in 599 ms (486 modules)
```
Total: 1.874ms (Note: This number is much higher when `pages/_app`
imports many modules).
#### After
```
- event compiled client and server successfully in 118 ms (20 modules)
- event compiled client and server successfully in 65 ms (20 modules)
```
📔 Note: opening the page then causes the Next.js / React runtime to be
compiled ofcourse
```
- event compiled client and server successfully in 115 ms (20 modules)
- event compiled client and server successfully in 57 ms (20 modules)
- event compiled client and server successfully in 1137 ms (361 modules)
```
Total: 1.309ms (Note: This number is not affected by`pages/_app`
importing many modules).
## How?
We can only apply this optimization after we've looped over the list of
on-demand entries, as that has the required metadata. Hence why I went
with deleting the keys for each respective type of entrypoint (`pages`,
`app`, `amp`).
<!-- 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 or adding/fixing 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: JJ Kasper <jj@jjsweb.site>
This breaks up some of our longest running tests which allows more
parallelizing of the tests. This also moves turbopack tests filtering
back to an allow list as it is running a lot of unrelated tests
currently which isn't ideal. We should only be running against tests
that are explicitly testing turbopack e.g. build tests should not be
duplicated in the turbopack group.
```sh
test/integration/css/test/group-1.test.js: 762.655
test/integration/edge-runtime-module-errors/test/index.test.js: 695.309
test/integration/css/test/group-2.test.js: 671.848
test/integration/i18n-support/test/index.test.js: 518.173
test/integration/scss-modules/test/index.test.js: 451.704
test/integration/css-features/test/index.test.js: 417.318
test/integration/css-modules/test/index.test.js: 403.405
test/integration/eslint/test/index.test.js: 381.563
test/integration/500-page/test/index.test.js: 371.134
test/integration/telemetry/test/index.test.js: 367.691
test/development/acceptance-app/ReactRefreshLogBox.test.ts: 335.878
test/integration/create-next-app/templates.test.ts: 334.01
test/integration/scss/test/group-2.test.js: 327.255
test/integration/scss/test/group-1.test.js: 318.574
test/integration/edge-runtime-configurable-guards/test/index.test.js: 313.834
test/e2e/instrumentation-hook/instrumentation-hook.test.ts: 294.618
test/development/acceptance-app/error-recovery.test.ts: 283.355
test/e2e/app-dir/app/vercel-speed-insights.test.ts: 278.242
test/integration/create-next-app/index.test.ts: 272.442
```
## Problem
Relative hash/query handling in `next/link` (e.g. `<Link
href="#hello">`) is broken in App Router, especially if you're on a
nested route.
This wasn't a problem in `/pages` because the href always get fully
resolved in `<NextLink>`; i.e. if you have `<Link href="#hash" />` on
`/hello`, it'll resolve the href to `/hello#hash` and use that
everywhere.
However, in App Router, `<Link>` no longer uses the current location to
resolve the href:
5451564f36/packages/next/src/client/link.tsx (L450-L457)
Therefore navigating with `new URL(href, location.origin)` will skip the
current path and always apply the relative hash/query to the _root_
route:
5451564f36/packages/next/src/client/components/app-router.tsx (L208-L215)
## Solution
Not 100% sure if this is the best solution, but since `app-router` is
already reading `window.location`, I'm using `location.href` as the base
URL to resolve the href.
I grep'd for `location.origin` and checked other callsites; seems like
only `app-router` deals with user specified hrefs.
Fixes https://github.com/vercel/next.js/issues/42157 &
https://github.com/vercel/next.js/issues/44139, and potentially
https://github.com/vercel/next.js/issues/48554 and
https://github.com/vercel/next.js/issues/22838
## Test Plan
```
pnpm testheadless test/e2e/app-dir/navigation
```
---------
This adds new `build and test` and `build and deploy` workflows in favor
of the existing massive `build, test, and deploy` workflow. Since the
new workflows will use `pull_request_target` this waits to remove the
existing workflow until the new one is tested.
While testing this new workflow flakey behavior in tests have also been
addressed. Along with the new workflow we will also be leveraging new
runners which allow us to run tests against the production binary of
`next-swc` so this avoids slight differences in tests we've seen due to
running against the dev binary.
Furthermore we will have a new flow for allowing workflow runs on PRs
from external forks which will either require a comment be checking a
box approving the run after each change or a label added by the team.
The new flow also no longer relies on `actions/cache` or similar which
have proven to be pretty unreliable.
Tests runs with the new workflow can be seen here
https://github.com/vercel/next.js/actions/runs/5100673508/jobs/9169416949
Since the static metadata routes should always be static that can be
optimized, they should be marked as default runtime (or basically no
runtime). This PR change the runtime detection, if it's a static
metadata route file, its runtime will be erased.
So that it won't be picked up by `edge-app-route-loader` and then by
`next-image-loader` which emits the unexpected static file
Fixes NEXT-1238
If using Server Actions on the client layer without enabling the
`serverActions` feature, the build should error. Add a test case to
ensure #50199 works.
Since there is no longer a limitation that requires us to static analyze
`process.env`, this PR removes it from the build process and updates the
corresponding documentation.
### What?
This reverts commit 6ebc725fe6 / #50247.
### Why?
#49972 is reverted due to bugs, and I'm retrying it.
### How?
Closes WEB-1072
Closes WEB-1097
Closes NEXT-1156 (as it's reopened by the revert PR)
fix#48469
---------
Co-authored-by: Shu Ding <g@shud.in>
### What?
Implement a CJS optimizer for next-swc
### Why?
x-ref: https://vercel.slack.com/archives/C02HY34AKME/p1684341093462309
Assuming most CJS files are transpiled from ESM, we can mimic
tree-shaking using an AST transform.
### How?
Closes WEB-1072
Fixes#48469
fix NEXT-1156
---------
Co-authored-by: Shu Ding <g@shud.in>
Fix react and react-dom aliases are not properly set for `pages/`
* Remove alias react-dom internals to `{}` in edge runtime as we're using server rendering stub as alias
* Add `react$`, `react-dom$` missing aliases
* Only apply alias to builtin react/react-dom when it's app dir assets.
* Add `react|react-dom/package.json` resolving to require-hook
* Fix hmr issue that sometimes it will perform a reload when a hard navigation is triggered
Currently the edge runtime does not support static generation so this adds a warning when `force-static` is leveraged with `edge-runtime` as it will cause unexpected behavior. Support is being investigated so this isn't a hard error at the moment.
x-ref: [slack thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1684783403551589)
## What?
After landing #49855 I found a few more edge cases with not-found not
behaving as expected:
- When navigating directly to a not-found page (e.g. `/testabc`) the
error boundary would not reset as there were multiple levels being
triggered at the same time.
- When running in production navigating back/forward to the not found
page caused the page to become empty
Both issues are fixed by this PR. I've added tests for both.
## How?
- Ensures `asNotFound` is not set on the layout-router, it causes all
levels to trigger not-found, even though only app-router needs it
- Ensures navigations to 404 are always a mpaNavigation (browser
navigation) instead of trying to do a client-side navigation (mirrors
what we do in `pages`)
Fixes NEXT-1209
Fixes NEXT-1218
Fixes#49823
<!-- 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 or adding/fixing 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 #
-->
client refs are not correctly extracted as we're using regex to get the exports names from cjs file. The regex was extracting some bad names from the code source, this PR fixes the regex to make sure they extract the correct content
Fixes NEXT-1213
As explained in the comments, the `cookies()` API is a mix of request and response cookies. For `.get()` methods, we want to return the request cookie if it exists. For mutative methods like `.set()`, we return the response cookie type instead.
fix#50049
fix NEXT-1211
Currently the suffix logic is for pages so nothing happens in app dir. This PR changes it to **always** apply the `createSuffixStream(closeTag)` transform, to defer `</body></html>` to the end of the stream.
fix#48372
fix NEXT-1200
* Adding default metadata to root not found under root layout
* Refactor the tests a bit, previously it only checks if the text existed in html, it actually exisits in flight response
Fixes#49979
Closes NEXT-1207
For static member expressions like `foo.bar`, we currently treat it as one whole Ident `foo.bar` and pass it over the `$$bound` array as one value. That causes a problem where the Ident inside the function body needs to be converted, because it can no longer access to `foo`.
Closes#49985.
fix NEXT-1206
## What?
@steven-tey noticed that on upstash.com that scrolling to hash keeps
happening regardless of the hash being set:
- Open site
- Click `Pricing` which adds `#pricing` and scrolls to the
`id="pricing"`
- Click `About`
- Click on the logo
You'll notice that navigating back to the homepage ends up scrolling to
the `id="pricing` instead of to the top of the page.
## How?
This happened because we didn't reset the `hashFragment` and
`segmentPaths` for scrolling when scroll was applied, which means it
would keep that value in the state and would be applied as such on
navigation.
This PR ensures that besides setting `apply` to `false` we also reset
the `hashFragment` and `segmentPaths`.
Fixes NEXT-1205
<!-- 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 or adding/fixing 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: JJ Kasper <jj@jjsweb.site>
This PR fixes a warning that previous looked like the following:
```
Warning: fetch for [object Request] specified "cache: default" and "revalidate: 60", only one should be specified.
```
## What?
Currently the error boundary state does not reset when a navigation
happens because the `key` does not change. Because of that navigating
using next/link when the error boundary is in the open state ends up not
rendering the contents of the new navigation, instead it keeps the error
boundary contents.
## How?
This PR uses a pattern that is recommended in the React docs (setState
during render) to reset the error boundary if the `usePathname` value
has changed, it is used as a proxy for a new navigation.
Fixes#47862
Fixes NEXT-963
Fixes#49736Fixes#49732Fixes#49599
<!-- 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 or adding/fixing 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 #
-->
metadataBase is using `process.env.PORT` to construct a host when there's no `metadataBase` specified in layout. Dev server needs to pass down the PORT env from the parent prcoess.
Fixes#49807Fixes#49859Closes#49889
Now that the beta docs have been merged into stable with the release of
13.4, this updates all links as some paths have changed due to
redirects.
---------
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This PR changes `useParams` to return all dynamic params present in the
tree as opposed to only those on the canonical/URL path
<!-- 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 or adding/fixing 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 #
-->
link NEXT-1108
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Follow-up to https://github.com/vercel/next.js/pull/49628 this updates
the `export const fetchCache` handling and `cache: 'no-store'` handling
as discussed which also aligns with our docs here
https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config#fetchcache
- `export const fetchCache = 'force-cache'`: forces all fetches to be
cached regardless of `cache: 'no-store'` but cacheable `revalidate`
values still take priority
- `export const fetchCache = 'default-cache'`: ensures fetches are
cached even if they come after a `cache: 'no-store'` fetch but don't
override `cache: 'no-store'` itself.
- without `export const fetchCache`, we still disable fetch cache for
successive fetches after a fetch that does `cache: 'no-store'`
x-ref: [slack
thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1683732826894469)
The `pathname` in app-render was actually "page" (e.g. `/blog/[slug]`),
with special url conventions. Instead we should use actual request url
as pathname. Rename previous `pathname` arg to `pagePath` for better
readability
Also improved the url validation
In Hot Reloader we use `mod.resource.replace(/\\/g, '/').includes(key)`
to see if the module is the entry. However that `includes` check isn't
solid. Say the entry key is `app/path/page`, these will all be matched:
```
app/path/page.js
app/path/page.css
app/unrelated/app/path/page/another/page.js
```
This PR fixes that and added a test case. I'm unsure if this fixes the
newly reported cases in #43396.
fix NEXT-1110
Fixes: #43598
This was a tricky one to find! Not sure why more people aren't
complaining about this issue, was super annoying in my use case since
links had the wrong URL.
## What?
This issue only occurred when basepath was defined and middleware and
dynamic pages are being used.
Example from the reproduction repo mentioned in the issue tagged:
<img width="686" alt="Screenshot 2023-04-23 at 9 32 55 PM"
src="https://user-images.githubusercontent.com/11258286/233850968-e14f6b49-858b-410e-b8f9-93c90447090a.png">
## Why?
`nextConfig` wasn't passed to `getNextPathnameInfo` function, hence the
basePath wasn't removed from a intermediate variable and that trickled
down to cause this issue.
Added test case based on the issue reproduction repo
---------
Co-authored-by: Jimmy Lai <laijimmy0@gmail.com>
This ensures we use the proper body stream when rewriting to an external
resource as currently it tries to consume an already read body stream.
Fixes: https://github.com/vercel/next.js/issues/48040
## What?
Removes `experimental.appDir` this was leftover from when I flipped the
switch.
Kept the config file as in the future we might add future flags and
such. It also helps that it has the types comment included so you always
get types.
<!-- 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 or adding/fixing 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: JJ Kasper <jj@jjsweb.site>
This fixes an existing bug where there're Server Actions defined in both the "server" and "client" layers (client imported Actions). They have the same worker name as they exist in one route entry, but they're built into different modules and compiled differently (server and client layers). Because of that, each route entry can have 2 "action module entries".
This PR adds the logic to differentiate that via a "layer" field so they don't conflict.
Fixes#48392
When passing down `Array<IconDescriptor>`, it should allow overriding `rel` prop of icon instead of always picking the default one
fix NEXT-1085
We picked `VERCEL_URL` env for `metadataBase` in preview mode, but also picking that on production, this could potentially use the unique build url for social images if you didn't set `metadataBase`
We recommend to set the major/preferred domain to `metadataBase` if you're using social images, this PR help warn you in every env if you're missing that
[slack thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1683150633962539?thread_ts=1683144147.664059&cid=C03KAR5DCKC)
This uses the new built-in progressive enhancement features of React.
These always use `multipart/form-data` atm. When one comes in that's not
a fetch, we can use `decodeAction` to get a resolved function.
This also ensures that we can test this by passing disableJavaScript to
tests. This disables JS for the context.
Fixes#49055, fixes#48918.
App dir will always require the server to run in the workers mode, so it
can keep a separate Node.js process for pages. This PR updates the
standalone server to initialize a "standalone server" (which works
similar to `start-server`), and changes the tracked files to include
Jest worker.
Adds proper `multipart/form-data` handling in the Edge runtime and fixes a bug (previously we are always using `serverActionsManifest.node`). For the form data, we just use `await webRequest.request.formData()` for now and will handle streaming later.
Fixes#48948
([repro](https://github.com/vercel/next.js/issues/48948#issuecomment-1533542001)).
When running inside a custom server with app dir, we should always opt
into the prebundled React with correct channels.
Thanks @karlhorky for help testing it!
Fixes#49169 too.
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
When using the `not-found.js` file to match missed routes, `serverCSSForEntries` will always be empty as the `ComponentMod.pages` itself doesn't contain any actual entry. We need to handle that as a special case.
Closes#48133.
For edge runtime, we're modifying `res.statusCode` in actions handler, but we didn't forward the `res` object to it, previously we're using a fake `res` `{}`. This PR fixes it so that the propery status code will be returned to the client
[slack-thread](https://vercel.slack.com/archives/C052S77L05C/p1682988777740609)
Follow up of #48867
- Statically optimize dynamic generated sitemap routes
- Previously the generated sitemap urls looks bit off
(`/route/sitemap.xml/[id]`), we polish it into `/route/sitemap/[id].xml`
in this PR
Not 100% convinced that this is the correct fix but it's the best I can
think of.
Previously, we would sometimes call location.assign()/.replace()
hundreds of times (or more) as I described in
https://github.com/vercel/next.js/issues/48438 and
https://github.com/vercel/next.js/issues/48309#issuecomment-1512290958.
Sometimes this would just make things slow but the navigation would
eventually succeed; sometimes this would just hang the browser.
Now we trigger it only once (or—for a reason I don't quite
understand—twice in dev, as you can see in the test) and never commit
that render.
This also fixes the bug I mentioned in
https://github.com/vercel/next.js/issues/48438#issuecomment-1528649776
where usePathname() and useSearchParams() would return the page we are
navigating to (even if that's an external page wholly unrelated to our
site!).
Fixes#48309, fixes#48438.
link NEXT-1028
Co-authored-by: Jimmy Lai <laijimmy0@gmail.com>
This ensures we properly handle edge runtime during build when loading pages as currently we are only check the page itself for the runtime flag although it can be nested higher up but we already have the relevant info in the middleware-manifest so we can use that during build.
Fixes:
```sh
info - Linting and checking validity of types
info - Collecting page data ..ReferenceError: self is not defined
at Object.<anonymous> (/Users/jj/dev/vercel/next.js/test/e2e/app-dir/app-edge/.next/server/app/edge/basic/page.js:1:1)
at Module._compile (node:internal/modules/cjs/loader:1254:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
at Module.load (node:internal/modules/cjs/loader:1117:32)
at Module._load (node:internal/modules/cjs/loader:958:12)
at Module.require (node:internal/modules/cjs/loader:1141:19)
at require (node:internal/modules/cjs/helpers:110:18)
at requirePage (/Users/jj/dev/vercel/next.js/packages/next/src/server/require.ts:126:10)
at <anonymous> (/Users/jj/dev/vercel/next.js/packages/next/src/server/load-components.ts:105:16)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
> Build error occurred
Error: Failed to collect page data for /edge/basic
```
* For sitemap if they're not using dynamic routes generation `generateSitemaps`, should optimize them as static sitemap
* For icons and social images, if they're not using `generateImageMetadata`, should optimize them as static path
Closes NEXT-1071
Fixes#48991
This PR renames `experimental.experimentalReact` as
`experimental.serverActions` and makes it a hard compilation error if
it's not set but detected server actions.
Closes#48807.
The issue seems to be introduced with recent React Float change, which isn't a real problem but a behavior change. Resources are layered by the `precedence` key and the style insertion logic can be simplified as "insert the new stylesheet right after the existing stylesheet in the same layer". When multiple stylesheets are inserted in the same render pass, their new order will be flipped.
This is a nice feature so we can always maintain the order of resources that might conflict.
### What?
Whenever you navigated and a page suspended through `loading` or an error happened caught by `error` in the first level of segments (e.g. `/dashboard` but not `/dashboard/settings`) scroll would not be applied. This happened because the focus and scroll handling component is rendered as part of `InnerLayoutRouter` and the Suspense / Error boundary was rendered **around** `InnerLayoutRouter`. This behavior is incorrect as we still want to immediately scroll to the place where the loading is rendered.
This PR fixes the behavior by allowing the scroll to apply to loading / error too.
### How?
Moved the scrolling component around the loading/error/innerlayout boundary and added tests.
This PR updates the way we preload fonts. Previously we tracked which
fonts we needed to preload for each layer and rendered a `<link
rel="preload" href="..." as="font" />` tag for each preloadable font.
This unfortunately gets blocked by data fetching and we want to be able
to hint these preloads as soon as possible. Now that React support Float
methods in RSC we can use `ReactDOM.preload(..., { as: "font" })` to
implement this functionality
This PR makes the following changes
1. expose a `preloadFont` method through the RSC graph
2. expose a `preconnect` metho through the RSC graph
3. refactor the preloads generation to use `preloadFont` instead of
rendering a preload link
4. If there are no fonts to preload but fonts are being used in CSS then
a `preconnect` asset origin is called instead of rendering a preconnect
link
5. instead of emitting a data attribute per font preload indicating
whether the project is using size-adjust we now emit a single global
meta tag. In the future we may get more granular about which fonts are
being size adjusted. In the meantime the current hueristic is to add
`-s` to the filename so it can still be inferred.
In the process of completing this work I discovered there were some bugs
in how the preconnect logic was originally implemented. Previously it
was possible to get multiple preconnects per render. Additionally the
preconnect href was always `"/"` which is not correct if you are hosting
your fonts at a CDN. The refactor fixed both of these issues
I want to do a larger refactor of the asset loading logic in App-Render
but I'll save that for a couple weeks from now
Additionally, the serialized output of preloads now omits the word
anonymous when using crossorigin so tests were updated to reflect
`crossorigin=""`
Additionally, tests were updated to no longer look for the size-adjust
data attribute on preloads
Additionally, There is a note about leaving a `{null}` render in place
to avoid a conflict with how the router models lazy trees. I'll follow
up with a PR addressing this
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
### What?
Implements resolving of `runtime` and `preferredRegion` in layouts. It
will resolve from the root layout down, each layout can override
`runtime` or `preferredRegion`.
```
app
├── layout.js -> export const runtime = 'edge'
├── page.js -> Edge runtime
└── dashboard
├── page.js -> Edge runtime
└── settings
├── layout.js -> export const runtime = 'nodejs'
└── page.js -> Node.js runtime
```
Adds support for `preferredRegion`. This is similar to `export const
config = { region: ['sfo1'] }` in `pages`.
However, there is a difference. It supports `export const
preferredRegion = 'home'` and `export const preferredRegion = 'edge'`.
`home` refers to the configured default region on your deployment
platform and `edge` refers to "all regions".
### How?
I've implemented a temporary resolving in `entries.ts`.
`preferredRegion` is tracked through the entry module in webpack which
is why it's added to all the loaders that create an entry module, this
prevents having to resolve/parse again later on.
Fixes NEXT-880
Fixes NEXT-1064
Fixes#48905Closes#48933
### What?
In #48928 we decided to error for the missing `id` from `generateImageMetadata` and `generateSitemaps` for better dev DX. This PR also refactors the metadata image urls generation that assumbling the utils together
* Fix the `generateImageMetadata` for non dynamic routes and related
`param` matching (Found during development)
* Fix dynamic routes with number suffix `(\d)` (Fixes#48689)
### What?
Exposing `globalThis.crypto`, based on [Node.js' WebCrypto
API](https://nodejs.org/api/globals.html#crypto_1)
### Why?
Similar to `fetch`, `crypto` is a popular API that is currently not
available on `globalThis` in all active Node.js versions yet.
This can help library authors to create runtime-agnostic packages.
### How?
Node.js already has the WebCrypto API that can be imported, we just
expose it on `globalThis` in Node.js versions where this is not
available.
Closes NEXT-1063
[Slack
thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1681821510191059)
This PR implements preloading of CSS from RSC.
1. The underlying Flight protocol was extended in
https://github.com/facebook/react/pull/26502 to allow sending hints from
RSC to SSR and Client runtimes. React was updated to include these
changes.
2. We now call `ReactDOM.preload()` for each stylesheet used in a
layout/page layer
There are a few implementation details to take note of
1. we were previously using the `.browser` variant of a few React
packages. This was a holdover from when there was just browser and node
and we wanted to use the browser variant b/c we wanted the same code to
work in edge/node runtimes. React now publishes a `.edge` variant which
is like `.browser` but expects to be server only. This is necessary to
get the opt-in for `AsyncLocalStorage`.
2. Even with the above change, AsyncLocalStorage was not patched on the
global scope until after React was loaded. I moved this into a module
which is loaded first
3. The component passed to RSC's `renderToReadableStream` is not
actually part of the RSC module graph. If I tried to call
`ReactDOM.preload()` inside that function or any other function defined
inside `app-render.tsx` file it would actually see the wrong instance of
`react-dom`. I added a new export on the RSC top level export which
exposes a `preloadStyle(...)` function which just delegates to
`ReactDOM.preload(...)`. This makes the preload run in the right module
graph
~There are a couple of bugs in React that this work uncovered that I
will upstream. We may want to delay merging until they are addressed.
I'll update this comment when that is complete.~
1. ~React, during SSR, can emit a preload for a style twice in some
circumstances because late discovered stylesheets don't consider whether
a preload has already been flushed when preparing to reveal a boundary
they are within~
2. ~React, during RSC updates on the client, can preload a style that is
already in the document because it currently only looks for existing
preload links and does not consider if there is a stylesheet link with
the same href.~
~both of these issues will not break functionality, they just make the
network tab look at bit more noisy. We would expect network deduping to
prevent multiple actual loads~
The above React bugs were fixed and included now in the React update in
this PR
---------
Co-authored-by: Shu Ding <g@shud.in>
### What?
Mux reported they're experiencing a specific case where scroll wasn't
applied. I've found a bug when the first element in a layout or page,
the one that React will return from `findDOMNode`, is display: hidden.
At that point the rect is is `0` `0` `0` `0` and the current logic
assumes that means it's in the viewport as it's top `0`.
In order to fix this I've looked at a few ways:
- Scrolling to top when the element is not visible
- Scrolling to the parent element that is visible
- **Scrolling to the closest sibling (nextSibling) of the element that
is visible**
Eventually I landed on the third option after looking at the Mux case,
my reproduction, and the way vercel.com's pages leveraging App Router
are structured.
### How?
Used a while loop to check if the domNode is visible, if not we continue
to the next sibling until one that is visible is found. If none are
found we bail on resolving further.
While looking into this it highlighted that we should add a global
scroll handler in app-router too for the case where none of the
layout-routers apply scroll. With this fix that is less urgent though so
I've added a todo.
Fixes NEXT-1056
<!-- 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 or adding/fixing 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 #
-->
### Why
Default font file of `@vercel/og` is not loaded, because the og package is bundled by webpack and we should external it so that `fs.readFileSync` is bundled and manged that can't be traced by nft.
### How
This PR externals `@vercel/og` so that they don't need to be bundled and files can be properly traced
Closes NEXT-1047
Fixes#48704
### What
For dynamic routes you might have different sitemap for different params
* Unloack using `sitemap.[ext]` in your app everywhere
* Support `generateSitemaps()` to create multiple sitemaps at the same time
### How
* Change the metadata regex to allow use sitemap in every routes
* Similar approach to `generateImageMetadata`, we make `sitemap.js` under dynamic routes to a catch all routes, and it can have multiple routes
Closes NEXT-1054
This PR changes `mutableCookies` from `RequestCookies` to a
`ResponseCookies` instance, and it now accepts extra options for each
cookie. Take a look at the tests for more details.
cc @styfle
---------
Co-authored-by: Steven <steven@ceriously.com>
Similar to #47922 but based off the latest server implementation and #48626:
> This PR implements the MutableRequestCookies instance for cookies() based on the current async context, so we can allow setting cookies in certain places such as Server Functions and Route handlers. Note that to support Route Handlers, we need to also implement the logic of merging Response's Set-Cookie header and the cookies() mutations, hence it's not included in this PR.
>
> fix [NEXT-942](https://linear.app/vercel/issue/NEXT-942)
This PR also adds the same support for Custom Routes.
cc @styfle.
fix NEXT-942, fix NEXT-941.
When you're using `config` object with `runtime` we'll show a warning and recomment you to move to `export const runtime = ...` for runtime property as it's documented as recommended. This PR adds a error for `next build` to avoid logs are truncated during multi-workers build and you're aware of the config which doesn't take effect with seeing the error
Follow up for #48630
link [NEXT-426](https://linear.app/vercel/issue/NEXT-426)
We currently use `URLSearchParams` to represent `FormData` but it's not really the same thing. And in Node.js 16 there's no `FormData` available so we can polyfill it via Undici.
Updates the name of Next.js Analytics to Next.js Speed Insights
closes ALY-579
---------
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
This PR implements new cache semantics for the app router on the client.
## Context
Currently, on the App Router, every Link navigation is prefetched and
kept forever in the cache. This means that once you visit it, you will
always see the same version of the page for the duration of your
navigation.
## This PR
This PR introduces new semantics for how the App Router will cache
during navigations. Here's a TL;DR of the changes:
- all navigations (prefetched/unprefetched) are cached for a maximum of
30s from the time it was last accessed or created (in this order).
- in addition to this, the App Router will cache differently depending
on the `prefetch` prop passed to a `<Link>` component:
- `prefetch={undefined}`/default behaviour:
- the router will prefetch the full page for static pages/partially for
dynamic pages
- if accessed within 30s, it will use the cache
- after that, if accessed within 5 mins, it will re-fetch and suspend
below the nearest loading.js
- after those 5 mins, it will re-fetch the full content (with a new
loading.js boundary)
- `prefetch={false}`:
- the router will not prefetch anything
- if accessed within 30s again, it will re-use the page
- after that, it will re-fetch fully
- `prefetch={true}`
- this will prefetch the full content of your page, dynamic or static
- if accessed within 5 mins, it will re-use the page
## Follow ups
- we may add another API to control the cache TTL at the page level
- a way to opt-in for prefetch on hover even with prefetch={false}
<!-- 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 or adding/fixing 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 #
-->
link NEXT-1011
### What
`export const runtime = 'experimental-edge'` also work for pages. This
PR add tests for that.
Closes NEXT-426
Follow up for #46631 that to fully remove all related code of the
`experimental.runtime`
Closes NEXT-684, closes#43396.
This PR implements a temporary workaround to address the issue that some
browsers are always caching CSS resources during the lifetime of a
session. We re-introduce the versioning query to the resource to avoid
that, and then use Mutation Observer to do GC manually on the client.
Once Float handles that by itself, we can probably remove this.
Note that correctly handling GC here is **required** for correctness,
not an optimization. That's why it took us a while to address this (even
this PR is still a temporary workaround). Imagine that if you have:
```css
h1 {
color: red;
}
```
and then you changed it to:
```css
h1 {
font-size: 300px;
}
```
During HMR, if we don't remove the old resources but only insert the new
one, both will be applied and you will still see the `<h1>` in red,
which is wrong.
Here's a recording of this PR working correctly in Firefox:
https://user-images.githubusercontent.com/3676859/233132831-b88e4d8d-aec9-48c4-9aa7-7c7a149b377d.mp4
Use should only need to configure one `metadataBase` as fixed domain or
url but metadata image routes can still work properly with `VERCEL_URL`
in preview deployments
If you configured `new URL('https://mydomain.com')`, it will work for
canonical url all the time since it's for SEO.
For preview deployments metadata image routes will work with deployment
url as they're always bound with deployment.
For production deployments metadata images routes can be alias to the
configured `metadataBase` as they could be the expected exposed domain
Follow up for #47910
link NEXT-887
x-ref: [slack
thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1681781435607369)
For static metadata files, we should always generate static routes
instead of generate dynamic routes, so that they won't be deployed as
serverless functions which executing file reading in deployment
Currently POST requests to `"use server"` entries are not correctly
handled, and this PR partially fixes the behavior. Note that the
`isMultipartAction` case is still missing as we can't simply use
`busboy`. Later we'll unify the implementation here to always use
FormData via Undici.
Fixes NEXT-1026.
We've supported `export const config = { ... }` to sepecify `runtime`
etc. configs for pages under `app/` for a while. This PR is going to
drop it and only support `export const [config name] = [config value]`
per config
Add a warning if the legacy usage is detectd
Closes NEXT-1016
### What?
This PR fixes misordered CSS `<link>` tags. CSS imports in inner layers
(e.g. a page) should always take precedence over outer layers (e.g. root
layout), but currently it's reversed.
### Why?
In layouts we usually define more general styles like globals, resets,
and layout specific things. And in inner layers and pages, things need
to be more detailed and override upper layers if there're any conflicts.
Previously we defined the component segment as
```tsx
<>
<Component {...props} />
{assets}
</>
```
which is necessary because of `findDOMNode` - if we put `assets` before
the component, we can't find the correct scrolling DOM and position for
that layer.
However, with `assets` being the last Float will receive the reversed
order of resources.
### How?
I changed the `createComponentTree` function to return a `Component` and
`assets` pair, so in the Layout Router they're no longer passed to the
scroll wrapper altogether but separately.
Closes NEXT-983
Fixes#47585, fixes#46347.
fix NEXT-656
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This PR fixes parallel routes navigation with `prefetch={false}`. This
was broken because the optimistic tree created when navigating with
prefetching disabled resulted in a state where the router tree was
expecting an incorrect node to be rendered and suspended until the
imaginary data arrived.
The fix consists of updating the method that creates the optimistic tree
in order to bailout of the optimistic tree creation when there are
multiple parallel routes for the current node.
<!--
## For Contributors
### Improving Documentation or adding/fixing 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 #
-->
fix#48122
link NEXT-1020
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
This PR fixes a bug with interception where the rewritten path passed an
incorrect segment data on production, resulting in a 404.
The fix consists of moving the rewrite pre-processing step that rewrites
the dynamic segment from the originating path to when we actually
generate the rewrite. This is needed because that step does not run on
production. Now it does and signals correctly to the app-render that the
value for the segment can be determined from the path.
Also enables prod testing, which I had forgotten to enable.
<!-- 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 or adding/fixing 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 #
-->
fix#48406
link NEXT-1017
### What?
* Support `generateMetadata(props)` to dynamically generate multiple
metadata images at the same time
```js
// /app/opengraph-image.tsx
import { ImageResponse } from 'next/server';
export async function generateImageMetadata({params}) {
const images = await ...;
return images.map((img, idx) => ({
size: { width: 1200, height: 600 },
alt: img.text,
contentType: 'image/png',
id: idx,
}));
}
export default async function ({params, id}) {
const text = await getTextFor(id);
return new ImageResponse(
(
<div
style={{...}}>
{text}
</div>),
{ width: 1200, height: 600 },
);
}
```
### How?
Use `<metadata image>/[[...__metadata_id__]]/route.js` to catch all
metadata images id, and then use this `params.__metadata_id__` as id
argument for dynamic generate image.
If there's param, then we create `<metadata image>/<id>`, if there's
only 1 static image without dynamic `generateImageMetadata` then we keep
use `<metadata image>`
Closes NEXT-896
This ensures we don't fail to return the full body when storing to
fetch-cache in edge-runtime. Also ensures the fetch cache tests are
running for Node.js v16 correctly.
Fetch handling was also failing on Node.js v16 due to react's use of
`res.clone()` being broken with undici which is fixed in the latest
version of edge-runtime so this bumps that.
x-ref: [slack
thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1681310566927429)
Ensure we handle the use-case where a React Server Component using
`fetch` encounters a `204` response.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
Fixes a bug where `fetch()` to a page that calls `redirect()` would hang
infinitely.
### How?
The `Location` header was missing. The reason this wasn't surfaced
before is that we also inject the `<meta>` tag to redirect which the
browser would pick up to redirect too.
Fixes NEXT-997
<!-- 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 or adding/fixing 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 #
-->
This PR fixes issues where rendering a new parallel route would reset
the scroll state of the page. This would be very apparent if you
scrolled down the page and opened a modal in a parallel route.
After a bit of investigating, I found out that the scroll behaviour
worked like this:
- after a navigation, we say to the router that we should auto-scroll if
possible
- but we don't specify which node of the tree should scroll
- so what happened is that the first router node to run the auto-scroll
effect would steal the auto-scroll, even though it might have been
destined for another node
The fix consists of
- when we received the flight patch, we compute all new segment paths
that will be rendered and add them to the scroll ref
- when the router says that we should autoscroll, the autoscroll
components will now read those paths and compare them with their segment
path and if yes, they will autoscroll
<!-- 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 or adding/fixing 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 #
-->
link NEXT-974
When collecting static icons we need both collect the one from layout
and page, but for root level route `/` we missed the `favicon.ico`
before so when other icon existed, the root page's collected icons will
cover root layout collected ones, which resulted into favicon missing
Fixes#48147
Closes NEXT-976
### What
Support `opengraph-image.alt.txt` and `twitter-image.alt.txt` for static
og/tw metadata image when they need to specify alt txt.
Closes NEXT-990
### Why
for og/tw images, you could have multiple images, so it's tricky to set
alt in metadata exports with alt text. For static case we want it can
work with static files, `.alt.txt` files will be the type to provide alt
text content
### What?
The change in #47985 breaks the URLs of static image files like
`/(group)/opengraph-image.png` to `/opengraph-image.png-012345`.
References from `/` are also broken.
### Why?
This is because only `opengraph-image.ts` and `opengraph-image.tsx` are
considered.
### How?
In this Pull Request, we are trying to solve the problem by including
similar support for `opengraph-image.png` and `opengraph-image.jpeg`.
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
This PR fixes an issue where throwing a notFound error in a parallel
route at the top level at the root level would trigger a notfound
boundary at the parallel route level, which meant in practice that you
could still see the other slots being rendered below.
This behaviour is undesirable and was caused by the fact that we were
inserting a default one at each top-level parallel route. This is not
longer needed as we have a global one in `app-router.tsx`
<!-- 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 or adding/fixing 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 #
-->
fixes NEXT-968
This PR adds a new marker for intercepting siblings routes + adds some
validation to intercepting routes ( you shouldn't use (..) at the top
level!)
also fixes a bug with any interception from `/` when navigating from a
child route
the new marker, `(.)`, makes it easier to model cases like
```
/profile/[id]
/profile/[id]/photos/[id]/
```
With the current syntax available, you’d need to do:
```with (..):
/profile/[id]/(..)[id]/photos/[id]
with (...):
/profile/[id]/(...)profile/[id]/photos/[id]
with (..)(..):
/profile/[id]/(..)(..)profile/[id]/photos/[id]
```
now, with (.)
```
/profile/[id]/(.)photos/[id]
```
<!-- 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 or adding/fixing 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 #
-->
link NEXT-935
also fixes NEXT-970
fixes NEXT-973
This PR basically adds support for processing multiple router payloads.
Previously we were only handling one payload at a time but now that we
introduced parallel routes, we need to be able to render and return
separate parts of the layout separately.
Before, the single payload was generated in a DFS manner: we traversed
the router state and rendered the first segment of the tree that we
found needed rendering. In practice, this meant that we could miss
adjacent segments that might need to be re-rendered as well.
Now, we iterate all branches of the tree and return an array of flight
patches to be applied on the client correctly.
fixes NEXT-971
<!-- 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 or adding/fixing 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 #
-->
This unblocks further optimization opportunities as well as fixes for
systematic problems such as NEXT-227. After this PR, only production
mode of non-app projects will be running on the legacy main process
mode.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
For now, this isn't a strong requirement as normal `fetch` requests will
still work with `react@next`. But in the future, form related props e.g.
`action=` and `formAction=` requires the experimental build.
Fixes NEXT-954.
Reverts vercel/next.js#48038
fix NEXT-926
---
The root cause was that when copying the package.json, I removed all
fields except for a few (such as `exports`) but missed the `browser`
field. That caused the client bundle to resolve to the Node.js version
of React DOM, and then we had the `async_hooks` error. Added it back in
99c9b9e51f8b0d4e4503ece9d07bce09161f3341.
I reproduced the error with next-site earlier and confirmed that this
fix is good.
### What?
Our current logic of detecting if a route allows dynamic params or not
(`fallback`) is flawed, and this PR fixes it.
### Why?
Right now, if no `generateStaticParams` is specified we return
`fallback: undefined` during dev. However, for an app with multiple
params, it may have multiple `generateStaticParams` defined in different
levels. If some level isn't covered by any `generateStaticParams`, we
still can't determine the fallback value.
### How?
I added a naive implementation to check if all params are covered by
`generateStaticParams` in the current or inner layers.
Closes NEXT-946
### What?
This PR makes the parent layout of parallel routes re-render when the
parallel route segments are different or when either of them has a
refetch marker.
Example:
```
.
└── app/
├── page.ts
├── layout.ts
├── foo/
│ └── page.ts
└── @modal/
├── default.js
└── foo/
└── page.ts
```
Here if you navigated to `/foo` from `/`, `@modal/foo/page` would never
get re-rendered because the tree would only re-render from
`foo/page.ts`.
This PR adds a check that checks the router state on navigation to see
if the parallel route segments diverge on navigation. Here we would be
checking that `@modal/default` is different from `@modal/page` so we
would re-render.
Also added some logic to make sure that refetch routes are processed
first when handling parallel routes.
### Why?
See example
Closes NEXT-966
Fixes #
<!-- 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 or adding/fixing 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 #
-->
With the addition of the query prefix we can hit the max length for PCRE
named matches so this reduces the prefix length and ensures we go
through the param name validation still
x-ref: https://twitter.com/simonecervini/status/1644123851003928579
