forked from vercel/next.js
-
Notifications
You must be signed in to change notification settings - Fork 0
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
pull
wants to merge
10,000
commits into
majacQ:canary
Choose a base branch
from
vercel:canary
base: canary
Could not load branches
Branch not found: {{ refName }}
Could not load tags
Nothing to show
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
+1,526,238
−431,644
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
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
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
force-pushed
the
canary
branch
5 times, most recently
from
October 25, 2022 16:15
df8579c
to
47e5ebe
Compare
ijjk
force-pushed
the
canary
branch
3 times, most recently
from
December 2, 2022 05:49
e078ebe
to
6b863fe
Compare
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
### 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
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]
Can you help keep this open source service alive? 💖 Please sponsor : )