[pull] canary from vercel:canary #2
Merged
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
During navigations, the `FlightDataPath` property from the server response can be an array if there are multiple parallel routes (eg, `children` and `slot`). When we apply server response to the router cache, we might call `applyFlightData` for each segment path, which will copy existing cache values and insert new ones depending on what changed. However, the `existingCache` argument that we pass to this function is the cache at the start of the navigation. That means subsequent calls to `applyFlightData` will reference the cache _before_ updates are made to it. This will cause it to erroneously think it needs to lazy fetch for missing data. <!-- 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 # -->
Update devdependecies tar and type. I have only imported the necessary function, maybe it is a little unverbose, we can use instead of ‘x’ => ‘extract’. --------- Co-authored-by: torresgol10.itd <[email protected]> Co-authored-by: Sam Ko <[email protected]>
### What
Remove creating client proxy for each ESM export, instead for ESM we
create a CJS module proxy for itself and access the property with export
name as the actual export.
### Why
`proxy` is the module proxy that we treat the module as a client
boundary.
For ESM, we access the property of the module proxy directly for each
export.
This is bit hacky that treating using a CJS like module proxy for ESM's
exports,
but this will avoid creating nested proxies for each export. It will be
improved in the future.
Notice that for `next/dynamic`, if you're doing a dynamic import of
client component in server component, and trying to access the named
export directly, it will error. Instead you need to align the dynamic
import resolved value wrapping with a `default:` property (e.g. `{
default: resolved }`) like what `React.lazy` accepted.
Revert #57301
Fixes #66212
x-ref:
[slack](https://vercel.slack.com/archives/C04DUD7EB1B/p1716897764858829)
### What Keep `test/e2e/app-dir/metadata-dynamic-routes/index.test.ts` with successful build cases, move the dev error tests into separate test ### Why x-ref: https://github.com/vercel/next.js/actions/runs/9429301722/job/25975574075?pr=66286 Before the moving the tests, the error is flaky with turbopack since the error will fail the hmr. Error observed with turbopack when seeing build failed cases. So I moved the tests into the separate dev tests, running inside sandboxes. Then each error test doesn't effect each other. ``` ⨯ ./app/metadata-base/unset/icon--metadata.js:1:1 Module not found: Can't resolve './icon.tsx' > 1 | import { generateImageMetadata } from "./icon.tsx" | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2 | import { fillMetadataSegment } from 'next/dist/lib/metadata/get-metadata-route' 3 | 4 | const imageModule = { generateImageMetadata } ```
Co-authored-by: Hendrik Liebau <[email protected]>
wording changes. <!-- 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: Delba de Oliveira <[email protected]>
#66477) ### What Optimizing the static generation for dynamic metadata routes If you're not using `generateSitemaps()` or `generateSitemaps()`, you don't need to change any file conventions. If you're using multi sitemap routes, make sure the returned `id` properties from `generateSitemaps()` don't need to contain `.xml`, since we'll always append one for you. Analyzing the exports of metadata routes and determine if we need to make them as dynamic routes. ### Why Previously, users are struggling with the multi routes of sitemap or images. For sitemap, the `.xml` extension in url doesn't get appended consistently to the multi sitemap route between dev and prod. For image routes, the generated image routes are always dynamic routes which cannot get static optimized. The reason is that we need to always generate a catch-all route (such as `/icon/[[...id]]` to handle both single route case (e.g. without `generateImageMetadata`, representing url `/icon`) or multi route (e.g. with `generateImageMetadata`, representing url `/icon/[id]`), only catch-all routes can do it. This approach fail the static optimization and make mapping url pretty difficult as parsing the file to check the module exports has to be done before it. #### Benifits For image routes urls, this approach could help on static generation such as single `/opengraph-image` route can be treated as static, and then it can get static optimized if possible. **Before**: `/opengraph-image/[[...id]]` cannot be optimized **After**: single route `/opengraph-image` and multi-route `/opengraph-image/[id]` are both possible to be statically optimized For sitemap, since we removed appending `.xml` for dynamic routes, it’s hard for users to have `/sitemap.xml` url with dynamic route convention `sitemap.js` . But users desire smooth migration and flexibility. **Before**: In v15 rc we removed the `.xml` appending that `sitemap.js` will generate url `/sitemap` makes users hard to migrate, as users need to re-submit the new sitemap url. **After**: Now we'll consistently generate the `.xml`. Single route will become `/sitemap.xml`, and multi route will become `/sitemap/[id].xml`. It's still better than v15 as the urls generation is consistent, no difference between dev and prod. Here's the url generation comparsion #### Before All the routes are dynamic which cannot be optimized, we only had a hacky optimization for prodution build multi-routes sitemap routes | | only default export | `export generateImageMetadata()` | `export generateSitemaps()` | | -- | -- | -- | -- | | opengraph-image.js | /opengraph-image/[[...id]] | /opengraph-image[[...id]]/ | /opengraph-image/[[...id]] | | sitemap.js | /sitemap/[[...id]] | /sitemap/[[...id]] | dev: `/sitemap/[[...id]]` prod: `/sitemap/[id]` | #### After Most of the single route will are to get statically optimized now, and the multi-routes sitemap are able to get SSG now | | only default export | `export generateImageMetadata()` | `export generateSitemaps()` | | -- | -- | -- | -- | | opengraph-image.js | /opengraph-image | /opengraph-image/[id] | - | | sitemap.js | /sitemap.xml | - | /sitemap/[id].xml | Next.js will have less overhead of mapping urls, we can easily multiply the urls generation simply based on file conventions. x-ref: feedback from #65507 Closes #66232
### What? This is a fix for a bundle potentially referring to two different external modules (e.g. `react` because it gets invalided from the require cache) See vercel/turborepo#7988 ### Turbopack Updates * vercel/turborepo#8376 <!-- Tim Neutkens - Rename ChunkLoading::None to ChunkLoading::Edge --> * vercel/turborepo#8371 <!-- Donny/강동윤 - test: Add an execution test for `paren_remover` --> * vercel/turborepo#8370 <!-- Tobias Koppers - Tree Shaking shared state and side effects --> * vercel/turborepo#7988 <!-- hrmny - feat(turbopack-ecmascript): cache external modules with wrapper --> Closes PACK-2622
…ehavior (#66151) The _requirement_ to export a `generateStaticParams` to get static cache behavior _after_ build time was _really_ surprising behavior for me, and I think others: * #62195 (comment) * #57961 (reply in thread) Potentially this is a bug, and not something that should be fixed with documentation? I don't understand next.js caching enough to make that determination, so instead I'm proposing these changes to docs which might be encountered by folks who are surprised by this cache behavior. One point in favor of this being a bug: The CLI reports that a route is `SSG` enabled in the build output, but doesn't actually cache post-build page renders if this export is missing. @awinogrodzki made a demo repo showing this behavior, as described [here](#57961 (reply in thread)). --------- Co-authored-by: Delba de Oliveira <[email protected]> Co-authored-by: Delba de Oliveira <[email protected]> Co-authored-by: samcx <[email protected]>
To assist with the development and testing of the new partial prerendering (PPR) paradigm, this introduces a stop-gap solution to let us verify issues with pages in preview and production environments if enabled. When a Next.js app is built and ran with the `__NEXT_EXPERIMENTAL_STATIC_SHELL_DEBUGGING=1` environment variable, pages that have PPR enabled in production and preview environments can have only their static shell served when accessed with a `?__nextppronly=1` query parameter. If your project is not using PPR, it will not change anything. If a page is accessed in production or development with the query parameter but PPR is not enabled, it will not change anything. Tests have been added to validate that going forward.
As discussed this adds handling to timeout at a max of 500ms for fetch cache request and retries a max of 3 times due to network instability. This also adds cache service tests and fixes a case we've been trying to track down where we were seeing `undefined` cache URL values which made debugging fetches tricky.
While investigating unexpected stale responses when leveraging `getStaticProps` on the 404 page noticed we have an inconsistency between local and deployed due to `Cache-Control` being set to `no-store, must-revalidate` even though a revalidate period is provided. The inconsistency also differs between the HTML response and the data response `_next/data` which causes even more unexpected behavior. To avoid this behavior, this replaces the handling to ensure we honor the originally provided revalidate period during `notFound: true` for the `Cache-Control` header. Validated against provided reproduction here https://github.com/fusdev0/next-notfound-revalidate Deployment: https://vercel.live/link/next-notfound-revalidate-govzskknf-vtest314-ijjk-testing.vercel.app/fallback-blocking/fasdf Prior PR for prior context that introduced this #19165 x-ref: [slack thread](https://vercel.slack.com/archives/C0676QZBWKS/p1717492459342109)
To allow us to incrementally adopt more comprehensive linting rules, this pull request disables the previous behaviour of failing CI when any warnings were discovered. Instead, this modifies the previous warnings to be errors which will preserve the previous linting behaviour. As we enable new lint rules, they can be added as warnings which will gently nudge us towards fixing in related pull requests.
This fixes some tests so that they can run on macOS that previously had some issues with IPv6 during testing as well as updated some of the tests to use `retry` over `check`.
## Why? Adding types to test—building on this [PR](#65722).
This test flakes a _lot_ ([ref](https://github.com/vercel/next.js/actions/runs/9456072960/job/26048162244), [ref](https://github.com/vercel/next.js/actions/runs/9456072960/attempts/2), [ref](https://github.com/vercel/next.js/actions/runs/9456076941/job/26048598801)) likely due to all of the `context` mutation and sharing between tests. This updates the test that fails the most with locally scoped context to flakes introduced by other 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 # -->
Update DevDependecy to the last version: @types/[email protected] Co-authored-by: torresgol10.itd <[email protected]>
This is causing unexpected errors. Reverts #66286
<details> <summary>React upstream changes</summary> - facebook/react#29835 </details>
When developing in Next.js repo, the maintainers / contributors sometimes need to build swc native files. Added a script `swc-build-native` to run the command `pnpm --filter=@next/swc build-native` which was verbose to run.
Noticed we weren't detecting test mode correctly due to incorrect args parsing so this fixes that x-ref: https://github.com/vercel/next.js/actions/runs/9725297814/job/26842454638?pr=67306#step:28:69
The Image Optimization API currently uses `parseInt()` for `w` and `q`
query string parameters.
This doesn't handle floats as you might expect and instead coerces, for
example `parseInt('99.9') === 99`.
This PR changes the runtime to match the build time validation and only
accept integers for `w` and `q`.
### Why? It could be confusing between `...` and `…`, which the later is actually a single character. ### How? We throw if we detect `…` instead of `...`.
Based on this discussion: #62681
### What * Warn with next.js when users customized `experimental.esmExternals` value * Add telemetry tracking on the customization usage for that flag. 0 for no customization, 1 for used non-default customized value ### Why `esmExternals` ideally can just remain as default value `true` which Next.js can handle the customization properly. Since next.js app router also supports it on canary now we're adding a warning to users that don't modify `esmExternals` option as it could affect module resolution on ESM packages.
### Why? Identified the bottleneck of Turbopack HMR, one of the reason is that we run `execSync` to get user's package manager and fetch their registry to get the latest & canary version of Next.js. This process was located at the initial of HMR, which could have been delayed to the initial of the error handling. ### How? - Remove getting user's package manager and just fetch from NPM regardless the user uses Yarn. - Used an async IIFE to await the promise of `getVerionInfo` value inside the synchronous `ws.handleUpgrade`. ### Benchmark > Benchmarked with console inside try-finally #### Webpack -- no cache | Version | Ready | |-------------------------------------|---------| | Canary | 1185ms | | Delta | 896ms | | Delta Webpack vs Canary Webpack | -24.39% | #### Turbopack | Version | Ready | |-------------------------------------|---------| | Canary | 1002ms | | Delta (Turbopack) | 509ms | | Delta Turbopack vs Canary Turbopack | -49.20% | --------- Co-authored-by: Jiachi Liu <[email protected]> Co-authored-by: Tobias Koppers <[email protected]>
…chPriority=high` (#67351) ## History When we added `priority` prop to `next/image`, there was no `fetchPriority` so we instead used this to preload the image in the head. Then when browsers added support `fetchPriority`, we automatically added `fetchPriority=high` when `priority={true}` to signal to the browser that this was a high priority image. This priority is added to the img and the preload. However, we saw cases where images are blocking critical css. Per @gnoff: > React currently prioritizes font preloads then high priority images, then css in the initial page load Due to these changes in React (aka Float), we should no longer set `fetchPriority=high`, although the user can still manually add that prop if needed.
This leverages [fetch priority](https://developer.mozilla.org/en-US/docs/Web/API/Request/Request#priority) to ensure automatic prefetching as a result of visiting a page is sent with "low" priority, to signal to the browser it can prioritize more important work necessary for rendering the page. A "temporary" prefetch (ie one that is created when there wasn't an existing prefetch cache entry on navigation) will use a "high" priority because it's critical to the navigation event. All other cases will be "auto" which is the current default.
When running `pnpm test-start test/production/standalone-mode/required-server-files/required-server-files.test.ts` locally, Jest hangs and prevents the process from exiting. In the CI, the issue is masked because `run-tests.js` uses `--forceExit`. The reason for the hanging process is that there are two server instances started, and only the last one is killed. By starting and killing the server for each test we can not only fix this, but also prevent the `should run middleware correctly (without minimalMode, with wasm)` test from affecting the other tests when flipping the `minimalMode` flag in `server.js`. I also reverted the darwin-specific overwrites of `appPort` that were added in #65722 and #66724. I don't think those are needed because after #65722 was created we did land #66285 which sets the hostname to be compatible with ipv4 and ipv6. If there's still a need to keep this then let me know, and I will restore it.
### What When PPR is off, app router prefetches will render the component tree up until it encounters a `loading` segment, at which point it'll just return some metadata about the segment and won't do any further rendering. This is an optimization to ensure prefetches are lightweight and don't potentially invoke expensive dynamic subtrees. However, there's a bug in this logic that is causing it to bail unexpectedly if a segment deeper in the tree contained a `loading.js` file. This would mean the loading state wouldn't be triggered until the second request for the full RSC data is initiated, resulting in an unintended delta between when a link is clicked and the loading state is shown. ### Why The `shouldSkipComponentTree` flag was incorrectly being set to `true` even if the `loading.js` segment appeared deeper in the tree. Prefetch requests from the client will always contain `FlightRouterState`, so the logic to check for loading deeper in the tree will always be missed. ### How This removes the `flightRouterState` check as it doesn't make sense: prefetches will currently _always_ include the `flightRouterState`, causing this to always short-circuit. I believe that this check is vestigial from when we were generating static `prefetch.rsc` outputs which is no longer the case. This mirrors a [similar check](https://github.com/vercel/next.js/blob/b87d8fc49983a3be568517d7ae14087749bb8ce3/packages/next/src/server/app-render/create-component-tree.tsx#L393) when determining if parallel route(s) should be rendered.
) ### What? Parallel routes build in a weird and render in a weird way. To render next.js always uses the last parallel route (alphabetically I think) as that's most likely to be the root. Building works in the opposite order, it goes from the first to the last. This is fine for the first render, but after that the renderer will only check if the file for the last parallel route has a bundle on disk and never request it to be updated. 1. match on routes 2. build match 3. check if the last parallel route bundle exists on disk - if it doesn't so go back to step 2 with the next match - the actual match gets thrown away 4. render with the bundle for the last parallel route The condition in step 3 will always be true after an update, because it was built for a previous request To fix this, turbopack will now emit all parallel routes that match a path every time one of them gets requested. Closes PACK-3078 Fixes #65836
### What? A test for #67222
### What? Fix a typo in docs. ### Why? The word *enable* was mistakenly written as *eanble*. ### How? Co-authored-by: Jiwon Choi <[email protected]>
### What?
Pass `module: "unknown"` to the minifier.
### Why?
It can minify both a module and a script. `module: "unknown"` lets the
parser to detect the type of the program.
The problematic library is `react-pdf` and next.js currently errors with
```
Failed to compile.
static/media/pdf.worker.1f09ce21.mjs from Terser
x 'import', and 'export' cannot be used outside of module code
,-[56104:1]
56104 | const pdfjsBuild = "0cec64437";
56105 |
56106 | var __webpack_exports__WorkerMessageHandler = __webpack_exports__.WorkerMessageHandler;
56107 | export { __webpack_exports__WorkerMessageHandler as WorkerMessageHandler };
: ^^^^^^
56108 |
56109 | //# sourceMappingURL=pdf.worker.mjs.map
`----
Caused by:
0: failed to parse input file
1: Syntax Error
Error:
x 'import', and 'export' cannot be used outside of module code
,-[56104:1]
```
### How?
Related:
#30237 (reply in thread)
Tobias Koppers - fix typo (vercel/turborepo#8619) Benjamin Woodruff - Store aggregate read/execute count statistics (vercel/turborepo#8286) Tobias Koppers - box InProgress task state (vercel/turborepo#8644) Tobias Koppers - Task Edges Set/List (vercel/turborepo#8624) Benjamin Woodruff - Memory: Use `triomphe::Arc` for `SharedReference` (vercel/turborepo#8622) Will Binns-Smith - chore: release npm packages (vercel/turborepo#8614) Will Binns-Smith - devlow-bench: add git branch and sha to datapoints (vercel/turborepo#8602) --- Fixes a `triomphe` package version conflict between turbopack and swc by bumping it from 0.1.11 to 0.1.13.
This PR adds font antialiasing to all the next.js templates (with css or tw). ### Before  ### After  Co-authored-by: Jiwon Choi <[email protected]>
### What When using `generateStaticParams` with interception routes, the interception would never occur, and instead an MPA navigation would take place to the targeted link. ### Why For interception rewrites, we use a `__NEXT_EMPTY_PARAM__` marker (in place of the actual param slot, eg `:locale`) for any params that are discovered prior to the interception marker. This is because during route resolution, the `params` for the interception route might not contain the same `params` for the page that triggered the interception. The dynamic params are then extracted from `FlightRouterState` at render time. However, when `generateStaticParams` is present, the `FlightRouterState` header is stripped from the request, so it isn't able to extract the dynamic params and so the router thinks the new tree is a new root layout, hence the MPA navigation. ### How This removes the `__NEXT_EMPTY_PARAM__` hack and several spots where we were forcing interception routes to be dynamic as a workaround to the above bug. Now when resolving the route, if the request was to an interception route, we extract the dynamic params from the request before constructing the final rewritten URL. This will ensure that the params from the "current" route are available in addition to the params from the interception route without needing to defer until render. Fixes #65192 Fixes #52880
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 : )