forked from vercel/next.js
-
Notifications
You must be signed in to change notification settings - Fork 2
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
pull
wants to merge
129
commits into
MLH-Fellowship:canary
Choose a base branch
from
vercel:canary
base: canary
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
+26,561
−18,508
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…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
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)
…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:  And after the changes:  --- Closes NDX-928
[diff facebook/react@029e8bd6...0ca3deeb](facebook/react@029e8bd...0ca3dee) <details> <summary>React upstream changes</summary> - facebook/react#32569 - facebook/react#32567 - facebook/react#32549 - facebook/react#32545 - facebook/react#32566 - facebook/react#32551 - facebook/react#32550 - facebook/react#32528 - facebook/react#32359 - facebook/react#32536 - facebook/react#32539 </details>
### 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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 : )