Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[pull] canary from vercel:canary #122

Open
wants to merge 10,000 commits into
base: canary
Choose a base branch
from
Open

[pull] canary from vercel:canary #122

wants to merge 10,000 commits into from

Conversation

pull[bot]
Copy link

@pull pull bot commented Jun 9, 2021

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

@pull pull bot added the ⤵️ pull label Jun 9, 2021
@atomist atomist bot added auto-branch-delete:on-close Delete branch when pull request gets closed auto-merge-method:merge Auto-merge with merge commit auto-merge:on-bpr-success Auto-merge on passed branch protection rule labels Jun 9, 2021
@pull pull bot added merge-conflict Resolve conflicts manually and removed auto-branch-delete:on-close Delete branch when pull request gets closed auto-merge-method:merge Auto-merge with merge commit auto-merge:on-bpr-success Auto-merge on passed branch protection rule labels Jun 9, 2021
@ijjk ijjk deleted the branch majacQ:canary October 20, 2022 16:39
@ijjk ijjk deleted the canary branch October 20, 2022 16:40
@ijjk ijjk force-pushed the canary branch 5 times, most recently from df8579c to 47e5ebe Compare October 25, 2022 16:15
@ijjk ijjk force-pushed the canary branch 3 times, most recently from e078ebe to 6b863fe Compare December 2, 2022 05:49
vercel-release-bot and others added 6 commits May 15, 2024 00:58
This auto-generated PR updates font data with latest available
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:

## For Contributors

### Improving Documentation

- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide

### Adding or Updating Examples

- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md

### Fixing a bug

- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md

### Adding a feature

- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md


## For Maintainers

- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
-->

### What?

Adding support for supporting a custom fontFamily name when using
next/font

### Why?

By default, next/font hashes the font name when generating css to
achieve proper scoping.
However, that makes it impossible to use next/font with 3rd party
libraries that provide CSS with pre-defined font names.

### How?

To solve this, I've added a new argument to the next/font function call
– `usedFontFamilyName`.
It allows developers to pick the fontFamily name that is going to be
used in the CSS output instead of the default one and make it work with
vendor CSS files.

```
import { Inter } from "next/font/google";

const inter = Inter({
  subsets: ["latin"],
  fixedFontFamily: "Inter",
});
```

Fixes [#43452](#43452)

---

Edit:

I've changed the implementation to use `disabledFontFamilyHashing`
boolean flag which removes the hashing but keeps the original font
family name instead of allowing a custom name

---------

Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
### Fixing a bug

fixes #65580 

### What?

#65580 

### Why?

Currently, afterInteractive is given as the default strategy prop, but
afterInteractive is not set for the child retrieved through
React.Children, and it is an empty prop and is not added to the script
loader, so the script is not executed.

### How?

Added item to script loader when `child.props.strategy` is undefined.

---------

Co-authored-by: JJ Kasper <jj@jjsweb.site>
Further enhancing the typings across the codebase, this resolves some
errors discovered while running tests. During development, previously,
if the websocket request was forwarded down to the route resolver, it
would fail. This is because a `Duplex` stream is not a `ServerResponse`.

I opted to use the `MockedResponse` here to ensure the remaining code
didn't change, as we're only using the resolve routes code to identify a
match rather than actually sending the response on. The response data is
sent later with the `proxyRequest` which here does have support for
`Duplex` streams.
…ta to the client (#64256)

### What?

This PR adds an experimental option `clientTraceMetadata` that will use
the existing OpenTelemetry functionality to propagate conventional
OpenTelemetry trace information to the client.

The propagation metadata is propagated to the client via meta tags,
having a `name` and a `content` attribute containing the value of the
tracing value:

```html
<html>
    <head>
        <meta name="baggage" content="key1=val1,key2=val2">
        <meta name="traceparent" content="00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01">
        <meta name="custom" content="foobar">
    </head>
</html>
```

The implementation adheres to OpenTelemetry as much as possible,
treating the meta tags as if they were tracing headers on outgoing
requests. The `clientTraceMetadata` will contain the keys of the
metadata that're going to injected for tracing purpose.

### Why?

Telemetry providers usually want to provide visibility across the entire
stack, meaning it is useful for users to be able to associate, for
example, web vitals on the client, with a span tree on the server. In
order to be able to correlate tracing events from the front- and
backend, it is necessary to share something like a trace ID or similar,
that the telemetry providers can pick up and stitch back together to
create a trace.

### How?

The tracer was extended with a method `getTracePropagationData()` that
returns the propagation data on the currently active OpenTelemetry
context.
We are using `makeGetServerInsertedHTML()` to inject the meta tags into
the HTML head for dynamic requests.
The meta tags are generated through using the newly added
`getTracePropagationData()` method on the tracer.

It is important to mention that **the trace information should only be
propagated for the initial loading of the page, including hard
navigations**. Any subsequent operations should not propagate trace data
from the server to the client, as the client generally is the root of
the trace. The exception is initial pageloads, since while the request
starts on the client, no JS has had the opportunity to run yet, meaning
there is no trace propagation on the client before the server hasn't
responded.

Situations that we do not want tracing information to be propagated from
the server to the client:
- _Prefetch requests._ Prefetches generally start on the client and are
already instrumented.
- _Any sort of static precomputation, including PPR._ If we include
trace information in static pages, it means that all clients that will
land on the static page will be part of the "precomputation" trace. This
would lead to gigantic traces with a ton of unrelated data that is not
useful. The special case is dev mode where it is likely fine to
propagate trace information, even for static content, since it is
usually not actually static in dev mode.
- _Clientside (soft) navigations._ Navigations start on the client and
are usually already instrumented.

### Alternatives considered

An implementation that purely lives in user-land could have been
implemented with `useServerInsertedHTML()`, however, that implementation
would be cumbersome for users to set up, since the implementation of
tracing would have to happen in a) the instrumentation hook, b) in a
client-component that is used in a top-level layout.

### Related issues/discussions

- #47660
- #62353 (Could be used as
an alternative to the server-timing header)
- getsentry/sentry-javascript#9571

---------

Co-authored-by: Jiachi Liu <inbox@huozhi.im>
### What

Disable auto polyfill for process in edge runtime.

### Why

React uses process.emit behind a typeof guard now. This leads to process
being bundled and process.emit being called which triggers build
warnings since we stub process APIs since they're not supported in Edge
runtime.

There's condition like `"object" === typeof process && "function" ===
typeof process.emit` in the react build now where the 2nd condition is
falsy. Stop polyfilling to skip that condition since it's mainly for
Node.js runtime

Related to #65692
sokra and others added 30 commits June 3, 2024 15:14
### What?

If the error message contains a reference to `node_modules` it would
omit the error message, but actually we only want to omit the stack
frames

### Why?

### How?
Hi 👋 Inlang dev here

This PR switches the Link to Inlang's i18n solution in the
Internationalization docs to point directly to
[Paraglide-Next](https://inlang.com/m/osslbuzt/paraglide-next-i18n)
since that's the most relevant page for NextJS developers looking for an
i18n library.

<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:

## For Contributors

### Improving Documentation

- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide

### Adding or Updating Examples

- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md

### Fixing a bug

- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md

### Adding a feature

- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md


## For Maintainers

- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change

### What?

### Why?

### How?

Closes NEXT-
Fixes #

-->

Co-authored-by: Sam Ko <sam@vercel.com>
One-word 'checkout' is a noun or adjective that refers to the act of
taking items out of a store after paying for them. 2. Two-words 'check
out' is a verb that refers to request someone to look at something.
Corrected the spelling of "checkout" to "check out" in the documentation
to improve readability and accuracy. This change ensures proper usage of
the phrase when referring to the installation guide.

<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:

## For Contributors

### Improving Documentation

- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide

### Adding or Updating Examples

- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md

### Fixing a bug

- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md

### Adding a feature

- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md


## For Maintainers

- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change

### What?

### Why?

### How?

Closes NEXT-
Fixes #

-->

Co-authored-by: Sam Ko <sam@vercel.com>
This adds details for every ISR cache request if the page being
requested supports PPR. If it does, it'll attempt to load the
`.prefetch.rsc` payload instead of the `.rsc` payload. This corrects a
bug that was present in deployed environments.

This additionally refactors the `isAppPPREnabled` out of most of the
application, as it's only used to determine if we should add to the
`prefetchDataRoute` fields in the `prerender-manifest.json`. To support
loading the prefetch file or not, we pass the `isRoutePPREnabled`
through with the cache get/set operations instead.

x-slack-ref:
https://vercel.slack.com/archives/C075MSFK9ML/p1717094328986429
This adds a new `layerAssets` property (containing styles and script
tags) to `FlightDataPath`. Previously these were lumped in with the
`head` node, but we intentionally only ever render a single `head`, to
avoid duplicating metadata. This would mean `<AppRouter />` would only
ever render imported stylesheets for a single page in a racey way.
However, since Float handles hoisting and deduping these style tags,
we're safe to render them for each segment.

This PR introduces no change in behavior, aside from sending
`layerAssets` down from the server and storing it in the client router
cache. These nodes aren't rendered -- this is done in #66300.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:

## For Contributors

### Improving Documentation

- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide

### Adding or Updating Examples

- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md

### Fixing a bug

- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md

### Adding a feature

- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md


## For Maintainers

- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change

Closes NEXT-
Fixes #

-->

### What?
This is an update on the documentation at the sitemap version history to
add the update (#53765) in
[v14.2.0](https://github.com/vercel/next.js/releases/tag/v14.2.0).
### Why?
I really appreciate that the next sitemap generator supports
localization. It would be great if we could see which version or higher
provides this support.

### How?
I added a new row at the top of the version history table.

---------

Co-authored-by: Sam Ko <sam@vercel.com>
This takes the `layerAssets` property from the previous PR and actually
renders it, replacing the previous style handling. This ensures that
when multiple page segments are rendered on screen, all of their
associated CSS files are loaded. The existing `findHeadInCache` method
only ever returns a single head node, which means it’d miss stylesheets.


Fixes #59308
Fixes #63465
### What?

* order of CSS between layout and page
* order of CSS between page and next/dynamic

### Why?

### How?

* overrides webpack CSS chunk loading to use react CSS loading to allow
them to share the order
### What?

optimize allocations in server actions transform

In one edge case it reduces allocations from 30GB to 4.5MB and time from
760ms to 11ms.

### Why?

make it faster
### What?

pass the correct prefer_esm value to the transform
### What?

Update `swc_core`

### Why?

To apply swc-project/swc#9019

It's required to use `swc_ecma_parser/tracing-spans`.

### How?
### What?

awaits generating the output before calling into emitting

### Why?

this improve the order of spans in the tracing
### What?

* add tracing for transforms
* add high level tracing
* add tracing for next/dynamic collection
This removes the previous `server/future` directory and moves everything
into the `server` or `server/lib` directories. This is aimed to start to
flatten the server application structure.
When `router.refresh` or a server action creates a new `CacheNode` tree,
we were erroneously not copying over the `loading` segment in the new
tree. This would cause the subtree to be remounted as the loading
segment switched from having a Suspense boundary to not having one.

Fixes #66029
Fixes #66499
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:

## For Contributors

### Improving Documentation

- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide

### Adding or Updating Examples

- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md

### Fixing a bug

- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md

### Adding a feature

- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md


## For Maintainers

- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change

### What?

### Why?

### How?

Closes NEXT-
Fixes #

-->

Co-authored-by: Sam Ko <sam@vercel.com>
We've been testing React v19 and we're mostly ready. Since we have a
number of upstream packages we have to update peer deps from:
```json
{
  "peerDependencies": {
    "react": "^18.3",
    "react-dom": "^18.3"
  }
}
```
to:
```json
{
  "peerDependencies": {
    "react": "^18.3 || ^19",
    "react-dom": "^18.3 || ^19"
  }
}
```
We are choosing to change the `next` semver from `latest` to `^14.2.3`.
This is to avoid the template from breaking after v15 becomes `latest`,
since package manager default behaviour doesn't handle conflicting peer
dep ranges for react very well 🙌
New PR

Update DevDependecies "validate-npm-package-name" and type

PR closed: #66420

---------

Co-authored-by: torresgol10.itd <torresgol10.itd@gmail.com>
Co-authored-by: Sam Ko <sam@vercel.com>
Properties such as the native `Headers` / `Cookies` on the `NextRequest`
proxy make use of internal slots, so passing `receiver` (the proxy
object) which does not have the internal slots on it causes an issue in
the edge runtime. Instead, we want to make sure that the target is the
native object. This is similar to
#47088.

<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:

## For Contributors

### Improving Documentation

- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide

### Adding or Updating Examples

- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md

### Fixing a bug

- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md

### Adding a feature

- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md


## For Maintainers

- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change

### What?

### Why?

### How?

Closes NEXT-
Fixes #

-->
[x-ref](https://github.com/vercel/next.js/actions/runs/9373686572/job/25809596665)

[x-ref](https://github.com/vercel/next.js/actions/runs/9369698964/job/25797174293#step:28:3566)

[x-ref](https://github.com/vercel/next.js/actions/runs/9358710911/job/25762395753#step:28:4509)

[x-ref](https://github.com/vercel/next.js/actions/runs/9377123789/job/25818561715?pr=66551#step:28:554)

<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:

## For Contributors

### Improving Documentation

- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide

### Adding or Updating Examples

- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md

### Fixing a bug

- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md

### Adding a feature

- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md


## For Maintainers

- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change

### What?

### Why?

### How?

Closes NEXT-
Fixes #

-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⤵️ pull merge-conflict Resolve conflicts manually
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet