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 #608

Open
wants to merge 129 commits into
base: canary
Choose a base branch
from
Open

Conversation

pull[bot]
Copy link

@pull pull bot commented Mar 1, 2025

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.1)

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

bgw and others added 5 commits February 28, 2025 14:13
…ted, not only on a fixed cron schedule (#76688)

I don't have a good way to test this without merging it first.
This restricts rspack to only be used with canary builds, and updates
the plugin’s readme to note this, along with its experimental state.

Test Plan: Made a custom build with a `__NEXT_VERSION` of `15.2.0` and
verified builds failed with the canary-only message.

---------

Co-authored-by: Zack Tanner <[email protected]>
Test Plan: `pnpm test-dev-rspack
test/development/acceptance/server-component-compiler-errors-in-pages.test.ts`
passes
…in dev (#76691)

Dev mode reports static/dynamic behavior using a heuristic when
dynamicIO is enabled. The heuristic previously incorrectly marked routes
as dynamic when they were in fact static as a consequence of refactoring
metadata to support streaming. This update adjust the heuristic to not
incorrectly assume dynamic in these situations.

The root cause is that errors in `onError` cannot be assumed to be valid
if the render has already aborted

Closes NAR-112
@pull pull bot added the ⤵️ pull label Mar 1, 2025
leerob and others added 24 commits March 1, 2025 12:38
These function the same, but the updated version looks cleaner.
<!-- 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 #

-->
…nav (#76692)

On client navigations, rendering does not start at the root, it starts
at the common layout down. As a result the existing heuristic to only
render the `<StreamingMetadata />` component once won't work, as
`children` will likely appear for parallel routes within the subtree.
(In other words: `children` is only useful as a heuristic for root
renders).

As a result, metadata will get duplicated on client navigation if
parallel routes match that page (this is because we iterate over all
parallel routes, and conditionally render `<StreamingMetadata />` based
on the flawed heuristic above)

Since the metadata tree is accumulated and only rendered once, ideally
it should never be rendered in `createComponentTree`. Or if it is, we
need to ensure it’s never rendered more than once, as it would contain
the same contents twice.

This PR:
- On client navs, ensures that we only render `<StreamingMetadata />`
once as part of the `rscHead`, rather than per parallel route segment:
[5e3686a](5e3686a)
- On the client, we make sure to prioritize the `head` node
corresponding with the root page slot ("children"). Otherwise we might
not render `<StreamingMetadata />` at all, since the current heuristic
would have early-returned for a parallel route that _didn't_ change as
part of the navigation (eg the case where a slot doesn't match, and
keeps rendering the previous node):
[7364e6e](7364e6e)
### What

streaming meatdata is fully enabled now, we don't need to pass down an extra flag through render options
### What?

Still look for effects even if a private property exists.

### Why?

It's valid ECMAScript input.

### How?

Closes #75938
## What?

Reuse the same code as is checked in page.js, making them consistent and
dropping an additional dependency which also makes it easier to run
while testing.

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

## For Contributors

### Improving Documentation

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

### Adding or Updating Examples

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

### Fixing a bug

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

### Adding a feature

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


## For Maintainers

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

### What?

### Why?

### How?

Closes NEXT-
Fixes #

-->
### What?

Compute module batches and refactor chunking to work on the batches graph instead of the modules graph

With many pages we run into the problem that each page has a lot of modules, even if the total amount of modules is not super high. This multiples the number of edges needed in our graph.

To reduce that, group modules to module batches and module batches to batch groups and query information on these batches resp. batch groups to reduce the work needed.

A module batch will be formed from modules that are always used in a specific execution order.
A batch group will be formed from module batches that are in the same chunk groups.

Usually we work with module batches in a certain order and a unordered list of batch groups. We query information from the batch group and sort the results based on the order of module batches.
This PR implements robust keyboard navigation for the Dev Tools dropdown
menu, and its nested overlays that appear.

Full list of changes:
- Use enum state `open` for making sure only one overlay can be open at
a time
- Implement proper focus trapping through `useFocusTrap` to make sure
focus can never leave the trap
- Fixed bugs related to focusing items in the menu
- Focused index in the menu is retained when closing a nested overlay
- Move all overlay-related logic to `DevToolsInfo`

_Note: We should follow up with an assessment of ARIA attributes on all
these surfaces_


https://github.com/user-attachments/assets/66a36359-1265-40dd-82cc-1032dfdcff28

Closes NDX-927
<!-- 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 #

-->
Reduces the main chunk's size for a hello world app ~from 60.2 kB to
51.6 kB~ from 53.5 kB to 45.6 kB (after #76622 got merged).

In the past we were a bit sloppy with using modules from `src/server`
also in universally used modules (server & browser). This led to code
ending up in browser chunks that's only meant for the server, e.g. async
local storage modules.

We did have already quite a few conditional requires with `typeof
window` checks for those modules, but not everywhere. This is fixed in
this PR. And shared modules are also moved out of `src/server` into
either `src/shared/lib` or `src/client`.

A simple smoke test is added to ensure we don't regress here, at least
for a simple hello world app. A better verification might be some kind
of linter rule though.

In addition, we don't remove the `typeof window` SWC optimization for
Next.js modules anymore (which is still done for other `node_modules`,
see #62051), to ensure that guarded code becomes dead code and is
eliminated.

Ideally, SWC would take care of the DCE solely by using `typeof window`
checks, without needing to manually split modules and dynamically
requiring them, which is very tedious and we'd like to avoid. But this
is currently not the case.

Another option worth exploring is using the ESM modules from
`next/dist/esm` in hopes of yielding better DCE results.
Because of eventual consistency
…ction instead of a turbo tasks function (#76628)

### What?

This avoids celling the input code for minification and passes is directly to magnification
Currently we only replace the first occurrence with
`String.prototype.replace()`. This uses `replaceAll` to replace all
occurrences.
    
Test Plan: See next PR in this stack for use.
Upon reading the documentation, I found the demo TypeScript code in
server components section is missing a close brace.

So adding it back to fix the issue. Thanks for reviewing!

<!-- 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: JJ Kasper <[email protected]>
### What

We discoved an issue that fetch new URL with static assets in Pages API on edge runtime were failing. Located the issue was an introduced in #66534 where we changed the layer of Pages API with edge runtime entries into API layer, where it actually should be another separate layer like middleware.

The quick fix is using middleware bundle layer for Pages API edge functions, but middleware is server-only layer which Pages API is not yet, since it doesn't bundle everything and picking up the `react-server` condition. So we have to create a new layer `apiEdge` to minimize the behavior changes and also fix the bug.

The test suite was disabled due to node-fetch blocker, but we now we can enable it.

Closes NDX-941
Fixes #74385 
[slack-ref](https://vercel.slack.com/archives/C07CGAA2RS6/p1740868643335099)
eps1lon and others added 30 commits March 8, 2025 12:18
### What?

Fix the span of the turbopack tree shaking magic comment.

### Why?

Previously it was printed on strange position.

### How?

Closes NAR-91

Closes PACK-4087
…ed panic (#76921)

User report: https://vercel.slack.com/archives/C046HAU4H7F/p1741216793060779
Appears to be fixed by: arthurprs/qfilter#8

```
Panic: panicked at turbopack/crates/turbo-persistence/src/static_sorted_file_builder.rs:114:18:
AQMF insert failed: CapacityExceeded
Backtrace:    0: _napi_register_module_v1
   1: _napi_register_module_v1
   2: <unknown>
   3: _napi_register_module_v1
   4: _napi_register_module_v1
   5: _napi_register_module_v1
   6: _napi_register_module_v1
   7: _napi_register_module_v1
   8: _napi_register_module_v1
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <unknown>
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: <unknown>
  23: <unknown>
  24: <unknown>
  25: <unknown>
  26: <unknown>
  27: <unknown>
  28: _napi_register_module_v1
  29: _napi_register_module_v1
  30: _napi_register_module_v1
  31: _napi_register_module_v1
  32: _napi_register_module_v1
  33: __pthread_deallocate
```
Seems the navigation from app -> pages can timeout from the retry in
development. This extends the timeout.
I think this should be safe to assume?
These are technically not entirely spec compliant as identical data urls in different folders aren't deduplicated (but each generate a new module). But this is good enough for now.

You can now do 
```js
import { bar } from "data:text/javascript,export var bar = 1234;";
import data from 'data:application/json,{ "foo": 1234 }';
import dataURLEncoded from 'data:application/json,%7B%20%22foo%22%3A%201234%20%7D';
import dataBase64Encoded from 'data:application/json;base64,eyAiZm9vIjogMTIzNCB9';
import "data:text/css,body { color: red }";

it("support data URL imports", () => {
  expect(bar).toEqual(1234);
  expect(data).toEqual({ foo: 1234 });
  expect(dataURLEncoded).toEqual({ foo: 1234 });
  expect(dataBase64Encoded).toEqual({ foo: 1234 });
});
```

Only data-urls in JS ESM imports are turned into modules. For JS, turning data-urls into separate modules is zero-cost, because they all end up in the same bundle anyway, but that is not the case for image data urls in CSS.
This implements a new napi binding, `project.writeAllEndpointsToDisk`
which writes chunks for all endpoints.

This avoids iterating over each endpoint and calling individual napi
bindings, each resulting in a call to `emit()`. While iterating entry
points now occurs in Rust, `OutputAssets` are collected in an `IndexSet`
to prevent unnecessary `emit()` calls. This also significantly reduces
unnecessary calls to the manifest loader from JS.

Test Plan: CI

Commit before removing merge commits:
189743d

---------

Co-authored-by: Tobias Koppers <[email protected]>
Co-authored-by: Tim Neutkens <[email protected]>
This includes `isRspack` in the following telemetry events, determining
it with the presence of `process.env.NEXT_RSPACK`:

- `NEXT_CLI_SESSION_STARTED`
- `NEXT_CLI_SESSION_STOPPED`
- `NEXT_BUILD_OPTIMIZED`

Test Plan: Verify these are included with `NEXT_TELEMETRY_DEBUG=1` for
both `next dev` and `next build`
This:
- Prompts users to report turbopack internal errors as new GitHub
discussions instead of issues
- Encodes the error message and debug information into the discussion
title and body respectively
- Since these encoded urls can be lengthy, it uses [Terminal
Hyperlinks](https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda)
to present things concisely without excessive wrapping. If the terminal
does not support this, only the error message is sent.
- Removes specific panic handling in favor of the `subscribe` napi error
handler. This seems to be the vast majority of panics.

Test Plan:

In a terminal with hyperlink support `FORCE_HYPERLINK=1 pnpm next dev
--turbo examples/basic-css/`:
```
-----
FATAL: An unexpected Turbopack error occurred. A panic log has been written to /var/folders/sk/zy7023wd30j0dxpmdv3nylm80000gn/T/next-panic-bf6bdb325db0f5ed5599cf332d8e364a.log.

To help make Turbopack better, report this error by clicking here.
-----
```

Where the link generated is [clicking
here.](https://github.com/vercel/next.js/discussions/new?category=error-report&title=Turbopack%20Error%3A%20Panic%20in%20AppProject%3A%3Anew%3A%20Some%28%22oh%20no%20new%20app%21%22%29&body=Error%20message%3A%0A%60%60%60%0APanic%20in%20AppProject%3A%3Anew%3A%20Some%28%22oh%20no%20new%20app%21%22%29%0A%0ADebug%20info%3A%0A-%20Execution%20of%20get_entrypoints_with_issues_operation%20failed%0A-%20Execution%20of%20EntrypointsOperation%3A%3Anew%20failed%0A-%20Execution%20of%20Project%3A%3Aentrypoints%20failed%0A-%20Execution%20of%20Project%3A%3Aapp_project%20failed%0A-%20Panic%20in%20AppProject%3A%3Anew%3A%20Some%28%22oh%20no%20new%20app%21%22%29%0A%60%60%60&labels=Turbopack,Turbopack%20Panic%20Backtrace)

In a terminal without hyperlink support `FORCE_HYPERLINK=0 pnpm next dev
--turbo examples/basic-css/`:

```
-----
FATAL: An unexpected Turbopack error occurred. A panic log has been written to /var/folders/sk/zy7023wd30j0dxpmdv3nylm80000gn/T/next-panic-3c5a833c682727cba1d51cc97ee0c16.log.

To help make Turbopack better, report this error by clicking here: https://github.com/vercel/next.js/discussions/new?category=error-report&title=Turbopack%20Error%3A%20Panic%20in%20AppProject%3A%3Anew%3A%20Some%28%22oh%20no%20new%20app%21%22%29&body=Error%20message%3A%0A%60%60%60%0ATurbopack%20Error%3A%20Panic%20in%20AppProject%3A%3Anew%3A%20Some%28%22oh%20no%20new%20app%21%22%29%0A%60%60%60&labels=Turbopack,Turbopack%20Panic%20Backtrace
-----
```

---------

Co-authored-by: Tobias Koppers <[email protected]>
## Why?

The cacheTag mention [here](https://nextjs.org/docs/app/api-reference/directives/use-cache#revalidating) makes it seem like cacheTag does the "revalidating," but actually this is still revalidateTag's job.

- Related: #76581
…e when object-fit `fill` is used instead of cover (#67482)

### What?
- Fixes #67478 

### Why?
- When an objectFit property that cannot be used for backgroundSize is
applied, I experienced an issue where the placeholder's size behaved
unexpectedly.

### How?
- Modify it to use 'cover' when the objectFit property cannot be used
for backgroundSize

---------

Co-authored-by: Sam Ko <[email protected]>
Co-authored-by: Steven <[email protected]>
Any suggestions regarding the exact naming?

```
"use turbopack no side effects"

export const bar = 123;
```
…76940)

### What?

Use the last side effect fragment instead of the module evaluation fragment.

### Why?

Module evaluation fragment is a waste of memory.

### How?

Closes PACK-3440

---------

Co-authored-by: Tobias Koppers <[email protected]>
This PR reverts our decision to use `rem` for the Dev Overlay surfaces. 

We have realised that using `rem` to style the Dev Overlays is not a
good idea because if an app sets their root font size to something tiny,
they will not have a great time using the Overlays, and it feels
unexpected to have the app root size leak into an external package.

I did not remove the references to `--size-*` CSS vars because we still
want to offer a way to scale the size of the UI, just through a custom
interface in the dropdown menu

---
- #76812
- Closes NDX-969
This PR applies `all: unset` to the `<select>` we use in Preferences for
the Dev Overlay and adds a custom icon because we lose the chevron as
soon as we apply this.

Why?

So the styling for the control would look more consistent, for example
this is what it looks like in Safari now:

![CleanShot 2025-03-11 at 12 36
12@2x](https://github.com/user-attachments/assets/a6da93ce-2b89-4420-8165-c58d4ec8ba29)

And after the changes:

![CleanShot 2025-03-11 at 12 36
24@2x](https://github.com/user-attachments/assets/4f0f4c31-cc0f-436b-9575-e4434c783b4e)

---
Closes NDX-928
### What
Adds support for Pinterest's Rich Pin Data meta tag, while
future-proofing for additional Pinterest tags.

This currently works like so

```js
pinterest: {
  richPin: true
}
  ```
 And would resolve to:
 
```html
 <meta property="pinterest-rich-pin" content="true" />
 ```

x-ref: https://help.pinterest.com/en/business/article/rich-pins

Closes #70873

---------

Co-authored-by: Dominik Koch <[email protected]>
### What

While adding a regression test for overlay JS bundle to ensure it's not
gonna existed in client bundles by asserting the source map.
Found that we're also including the indicator reducer from client JS
bundles. This PR ensure we fully strips it out
This brings back the env inlining step separate of compilation used for
the [flying shuttle
experiment](#73710) so that when
`next build --experimental-build-mode=compile` is used we don't inline
these values so that these artifacts can be cached/reused independent of
the env values. Then `next build --experimental-build-mode=generate` can
be used to inline the values and run prerendering to generate finalized
build.
Builds on #76814

Closes PACK-4071 (implementing config.deploymentId)

This uses the new `__turbopack_load_by_url__` to load chunks through
client references in react-dom-turbopack.

After this lands I'm going to send a PR to react-dom-turbopack to switch
the original source to use `__turbopack_load_by_url__` too, landing this
PR first to make sure it passes all the Next.js tests.

<!-- 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 #

-->
Make it clear this is not a real function
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.