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 #3
Merged
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
Because the next-error-code-swc-plugin crate uses the wasm32-wasip1 target, including it in the workspace causes cargo check to fail, which in turn causes the main build to fail. To work around this, I'm removing the crate from the workspace.
This pull request adds a more prominent error message to the CI build failure message when a new error message is added through `new Error(...)` but `pnpm build` has not been run locally to update `errors.json`. **Example** ![CleanShot 2024-12-11 at 13 38 52@2x](https://github.com/user-attachments/assets/6ab89823-4dc9-4bf2-a8a5-eae9a53e1fd0)
…c`s and `OperationVc`s (#73764) This is a follow-up to #73714 **What is NonLocalValue?** https://turbopack-rust-docs.vercel.sh/rustdoc/turbo_tasks/trait.NonLocalValue.html The core change here is this bit in `turbopack/crates/turbo-tasks/src/vc/local.rs`: ```diff - unsafe impl<T: ?Sized + NonLocalValue> NonLocalValue for OperationVc<T> {} - unsafe impl<T: ?Sized + NonLocalValue> NonLocalValue for ResolvedVc<T> {} + unsafe impl<T: ?Sized> NonLocalValue for OperationVc<T> {} + unsafe impl<T: ?Sized> NonLocalValue for ResolvedVc<T> {} ``` These new implementations are intentionally incorrect, as these values `T` could contain references to local `Vc` values. We must also check that `T: NonLocalValue`. However, we're temporarily ignoring that problem, as: - We don't *currently* depend on `NonLocalValue` for safety (local tasks aren't enabled). - We intend to make all `VcValueType`s implement `NonLocalValue`, so implementing this for all values is approximating that future state. - Adding a `T: NonLocalValue` bound introduces a lot of noise that isn't directly actionable for types that include a `ResolvedVc` or `OperationVc` that is not *yet* a `NonLocalValue`. This PR also adds the `NonLocalValue` to types explicitly deriving `TraceRawVcs`, for types that couldn't before, by using the new weaker bounds on the `NonLocalValue` impls.
Co-authored-by: Delba de Oliveira <[email protected]> Co-authored-by: Lee Robinson <[email protected]>
Follow-up to #73715. Since PPR should always result in a cache hit for a prefetch (even in the worst case, there's a fallback cache entry), the only reason a route tree prefetch would not be found in the per-segment cache is because PPR is disabled. So we should just fallthrough to the old prefetching flow whenever PPR is disabled. But the client still needs some way to tell whether the response was served from the per-segment cache or by the old implementation. So I added an explicit response header to every per-segment prefetch. If the header is missing, the client can infer that the route does not support PPR.
### What? Update `swc_core` to https://github.com/swc-project/swc/releases/tag/swc_core%40v9.0.0 ### Why? To keep in sync
if we're on windows and the path happens to be absolute, not escaping the path can lead to generating invalid code. for example, with a path like `C:\Users\notgood\...`, the `\n` **will be interpreted as a newline** when the module is parsed, and thus blow up multiple things downstream
LayoutRouter has changed significantly since it was originally written and the structure has become harder to follow. One thing I always find confusing whenever I'm reading this code is that some of the values correspond the the *parent* segment, while others correspond to the *current* segment. So this moves the code around a bit and updates the names so it's clearer which parts belong to which segments. While working on this, I noticed a funny thing about how loading boundaries work that was made more obvious by the revised naming. I've left a TODO comment to follow up on whether this was intentional.
Based on: - #73540 --- Currently if you navigate to a partially static route, the server will always start rendering at the first segment that's not present on the previous page. However, it should really start rendering at the first *dynamic* segment — if the client has already prefetched a segment, and it's fully static, there's no reason to render it again during the dynamic server render. We can do this by sending a more specific Next-Router-State-Tree request header. Rather than send a tree that represents the previous route, we sent the tree of the target route, but with a `refetch` marker added to the first dynamic segment. (Without the refetch marker, the server would send back an empty response.) This is determined by diffing against both the previous route *and* the prefetch cache. For now, this only works up to the first dynamic segment inside the new subtree; once the server starts rendering along a path, it renders everything else along that path. We could improve this in the future to also omit static segments that appear inside a dynamic layout, though this would likely require a change to the Next-Router-State-Tree protocol.
When the client Segment Cache attempts to prefetch a route tree, and it the route does not have PPR enabled, the server falls through to the old implementation, which sends back a FlightRouterState. This is fine, since the client can use the FlightRouterState to recreate the non-PPR behavior. However, when loading.tsx is present in the route, the server will not just send back the FlightRouterState, but also render the page up to the first loading boundary. This is not what we want in the Segment Cache implementation — we want the route tree only, so we can determine which parts the client already has before sending a second request for the rest. So this PR disables the loading.tsx mechanism when prefetching the route tree, by checking the Next-Router-Segment-Prefetch header.
Based on: - #73826 --- This removes the `segmentPath` prop from the LayoutRouter payload. This can be derived on the client from the FlightRouterState instead.
## Summary Both `app/actions.ts` and `app/action.js` aren't JSX in [error handling](https://nextjs.org/docs/app/building-your-application/routing/error-handling) docs. `app/api/route.ts` and `app/api/route.js` aren't also JSX in [after](https://nextjs.org/docs/app/api-reference/functions/after) docs. ### Improving Documentation - [x] Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - [x] Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide Co-authored-by: JJ Kasper <[email protected]>
if this `fetch` fails it's kinda annoying to find, because it just gets printed as ``` │ [17:05:40] precompile failed because fetch failed ``` this change should at least make it easier to find the cause by searching for the error message: ``` │ [17:20:27] precompile failed because Failed to fetch AMP validator ```
## Problem When generating route regular expressions for data routes, some code paths appear to not escape the `.` in `.json`. This causes routing to be slightly slower, prevents some optimizations related to static postfixes, and potentially allows for unintended request paths to be accepted as value. ## Solution After much tracing and digging, I found a code path writing regular expressions directly without escaping. In this case the solution is to escape the `.` using `\\.` when generating static data routes. A simple next app was made to exercise this path with a route `pages/server-time.tsx` that contains a simple `getServerSideProps`. ```tsx import type { InferGetServerSidePropsType, GetServerSideProps } from 'next' type TimeDate = { timestamp: number } export const getServerSideProps = (async () => { return { props: { timestamp: Date.now() } } }) satisfies GetServerSideProps<TimeDate> export default function Page({ timestamp, }: InferGetServerSidePropsType<typeof getServerSideProps>) { return ( <main> <p>{new Date(timestamp).toUTCString()}</p> </main> ) } ``` Before the change, the generated route regexp was `"^/_next/data/[build_id]/server-time.json$"`, but after then change it becomes `"^/_next/data/[build_id]/server-time\\.json$"` The related tests were updated to expect properly escaped `\\.json$` endings to the regexps.
Builds are failing on canary so attempting revert to allow investigation separate x-ref: https://github.com/vercel/next.js/actions/runs/12292495270/job/34303267911 x-ref: https://github.com/vercel/next.js/actions/runs/12292495270/job/34303267654 x-ref: https://github.com/vercel/next.js/actions/runs/12292495270/job/34303267358 Reverts #73696
…72095) # What This PR fixes a bug when using next@15, next/dynamic and assetPrefix config in App Router. # Why The current behavior loads the CSS with only the pathname and so, it results with a 404. # How The new behavior uses the full url of the asset. Fixes #72470 <!-- 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: Tobias Koppers <[email protected]> Co-authored-by: JJ Kasper <[email protected]>
…_trait macros (#73766) **Recommendation:** Review [the individual commits](https://github.com/vercel/next.js/pull/73766/commits) in order! **What is NonLocalValue?** https://turbopack-rust-docs.vercel.sh/rustdoc/turbo_tasks/trait.NonLocalValue.html 1. Switches the default behavior of `#[turbo_tasks::value]` and `#[turbo_tasks::value_trait]` to derive `NonLocalValue`, with an opt-out (previously, this was just opt-in). 2. *(Automated, codemod)* Remove pre-existing opt-ins to `NonLocalValue` (as this is now the default behavior) 3. Manually add `NonLocalValue` to a couple more common types. 4. *(Automated, codemod)* Add `local` annotations to structs and traits with errors. Normally I'd split this sort of thing up across a few PRs, but steps 1, 2, and 4 must be atomic (must land together). --- Removing pre-existing opt-ins was done with a couple regexes: ``` fastmod --accept-all '#\[turbo_tasks::value(?<trait>_trait)?\(((?<prefix>.*), )?non_local(?<suffix>.*)\)\]' '#[turbo_tasks::value${trait}(${prefix}${suffix})]' fastmod --accept-all '#\[turbo_tasks::value(?<trait>_trait)?\(\)\]' '#[turbo_tasks::value${trait}]' ``` Adding `local` annotations to structs/enums and traits was done with this kludge (partially sourced from chatgpt): ``` cargo check --message-format=json 2>/dev/null | jq -r '. | select(.message.children != null) | .message.children[] | select(.spans != null) | .spans[] | select(.expansion.macro_decl_name == "#[derive(turbo_tasks::NonLocalValue)]") | .file_name + " " + (.line_start|tostring) + " " + (.line_end|tostring)' | sort -u | xargs -I{} bash -c 'args=($1); file="${args[0]}"; line="${args[1]}"; echo "Processing: $file $line" >&2; sed -i "${line}s/#\[turbo_tasks::value(\([^)]*\))\]/#[turbo_tasks::value(\1, local)]/; ${line}s/#\[turbo_tasks::value\]/#[turbo_tasks::value(local)]/" "$file"' -- {} && \ cargo check --message-format=json 2>/dev/null | jq -r '. | select(.message.children != null) | .message.children[] | select(.spans != null) | .spans[] | select(.expansion.macro_decl_name == "#[turbo_tasks::value_trait]") | .file_name + " " + (.line_start|tostring) + " " + (.line_end|tostring)' | sort -u | xargs -I{} bash -c 'args=($1); file="${args[0]}"; line="${args[1]}"; echo "Processing: $file $line" >&2; sed -i "${line}s/#\[turbo_tasks::value_trait(\([^)]*\))\]/#[turbo_tasks::value_trait(\1, local)]/; ${line}s/#\[turbo_tasks::value_trait\]/#[turbo_tasks::value_trait(local)]/" "$file"' -- {} ``` Which I just ran a bunch of times until `cargo check` no longer generated any errors.
… `T: NonLocalValue` (#73770) Title says it all. This lets us implement `NonLocalValue` on more structs. **What is NonLocalValue?** https://turbopack-rust-docs.vercel.sh/rustdoc/turbo_tasks/trait.NonLocalValue.html
## Why? Fix typo.
) These APIs are under development and haven't been announced. We are not recommending people use it yet. CloseS: https://linear.app/vercel/issue/DOC-4038/remove-the-unstable-expiretag-and-unstable-expirepath-docs-as-the Context: https://vercel.slack.com/archives/C06DGJ420TZ/p1733916966674099 Redirects: vercel/front#39875
This PR separated the error message component. ### Light ![CleanShot 2025-01-06 at 18 20 31](https://github.com/user-attachments/assets/3379bf69-743c-4431-8e03-e051be7f30e2) ### Dark ![CleanShot 2025-01-06 at 18 21 47](https://github.com/user-attachments/assets/d70309c5-df35-4f32-82a6-e9776976c632) Closes NDX-608
This PR added the error type label. ### Light ![CleanShot 2025-01-06 at 19 08 56](https://github.com/user-attachments/assets/1e85d19e-b989-4e1a-914d-567abfb309d2) ### Dark ![CleanShot 2025-01-06 at 19 08 50](https://github.com/user-attachments/assets/c5d2e6a6-f43e-4134-b1b7-0dc13eb83cd4) Closes NDX-607
We're adding a new feature to the error overlay that allows developers to rate the current error message. Developers can rate the error message by clicking on the thumb up or down icon in the error overlay footer. This pull request adds the click handler for the error rating buttons. When the buttons are clicked, the click handler calls a previously implemented internal API endpoint. The endpoint is connected to the usual Next.js Telemetry. To test the UI, run `pnpm storybook` and go to http://localhost:6006/?path=/story/erroroverlaylayout--default. https://github.com/user-attachments/assets/6daf6e64-e8bb-4e5e-b282-082086f1e529
Fast-follow to @acdlite's comment #74473 (comment)
### Improving Documentation I was just upgrading from Next.js v13 to v14 following this guide: https://nextjs.org/docs/app/building-your-application/upgrading/version-14 npm installation throws the below error: ```sh npm error code ERESOLVE npm error ERESOLVE unable to resolve dependency tree npm error npm error While resolving: [email protected] npm error Found: [email protected] npm error node_modules/react npm error react@"19.0.0" from the root project npm error npm error Could not resolve dependency: npm error peer react@"^18.2.0" from [email protected] npm error node_modules/next npm error next@"14.2.21" from the root project npm error npm error Fix the upstream dependency conflict, or retry npm error this command with --force or --legacy-peer-deps npm error to accept an incorrect (and potentially broken) dependency resolution. ``` The react version for Next.js v14 should be pinned to react@18.
Improved a11y (aria-live, aria-label) and simplified loading/error state to prevent double firing when feedback buttons get clicked multiple times while loading.
## What? Added accessibility improvements to the error overlay voting buttons by making their icons properly hidden from screen readers. ## Why? To enhance accessibility for users relying on screen readers by preventing redundant icon announcements while maintaining the clear button labels "Mark as helpful" and "Mark as not helpful". ## How? - Added `ComponentProps<'svg'>` type to ThumbsUp and ThumbsDown components to allow passing SVG attributes - Spread props to SVG elements to enable aria attributes - Added test coverage to ensure icons have `aria-hidden="true"`
This auto-generated PR updates font data with latest available
## Why? - Update React in reproduction example templates to stable v19 - Switch `.ts` for `next.config` - Fixes #74422
## Why? Updating from `STALE_TOKEN` to `RELEASE_BOT_TOKEN` because `STALE_TOKEN` has expired.
Fixes #74062 (`jotai` ran into this error [when they added `"type": "commonjs"` to their package.json](pmndrs/jotai#2579 (reply in thread))) > this is a bug in the transform we do when a `'use client'` directive is encountered. I think what's happening is that we're creating a virtual file that uses ESM import/export syntax, but it's called proxy.js (not proxy.mjs), so the `"type": "commonjs" `makes turbopack "correctly" upset at the ESM syntax. #74062 (comment) The (slightly kludgy) solution is to use `proxy.mjs` or `proxy.cjs` to force the module format, bypassing the issue where `proxy.js` changes meaning depending on `package.json#type`.
### What? updates shadow-rs dependency, which fixes the build.rs caching problem: https://github.com/baoyachi/shadow-rs/pull/195/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R40 Also prints the git version during the build
This PR added style for Toolbar buttons, and moved files to `Errors/error-overlay-toolbar`. Will follow up with TBD: - Replace the Node.js button with the "Debugging" Icon - Add Docs Button? ### Light ![CleanShot 2025-01-07 at 01 12 52](https://github.com/user-attachments/assets/a26ad870-d938-4b24-a8e7-2409e65026d1) ### Dark ![CleanShot 2025-01-07 at 01 12 25](https://github.com/user-attachments/assets/0abe5d67-677b-4002-bf43-6d7a26dee602) Closes NDX-601 Closes NDX-602
this comment is a useful explanation, but was accidentally lost in #52846, when a bunch of loader stuff was unified between webpack and turbopack see: https://github.com/vercel/next.js/pull/52846/files#diff-173d1bc6424869c0d3c43f8fba124186427d03e5bd056587f141886a0075b1d3L699-L700
## What? Skips the websocket ping for Turbopack. Currently the ping is only used by the webpack integration to keep track of "active" entrypoints that are still being viewed. Entrypoints that are no longer viewed will be disposed from the webpack compiler. With Turbopack this mechanism is not used and it keeps the entrypoints around. Removing the ping makes the websocket events easier to monitor and read while debugging. <!-- 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 # -->
This ensures we don't lose tags added to a page before `notFound()` is called as otherwise a fetch on the page that has been revalidated won't be able to be applied correctly if dropped from a `notFound()` call. This was broken recently in the refactors of handling rendering in app-render as it worked correctly in `v14`. x-ref: [slack thread](https://vercel.slack.com/archives/C04V3E1UYNQ/p1736200963684869) Closes https://linear.app/vercel/issue/ENET-1381 Closes https://linear.app/vercel/issue/NEXT-3946 Closes #73973 Closes #66540
While many use case-specific graphs belong in Next.js, this primitive should be kept in Turbopack as it will be used for other core usecases like chunking. Test Plan: CI
This PR allows `.stories.tsx` files to be viewed as nested when they share the same filename with `.ts` and `.tsx`, similar to the `.test.` files. https://github.com/user-attachments/assets/8e280369-984d-4d33-b91a-392b3c18b5d9
Prerender errors triggered during development should be rethrown by the `unstable_rethrow` api. <!-- 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 # -->
…App router (#74440) This PR updates the with-react-jss example to use the App Router. Here are the changes that have been made: - Renamed the `pages` folder to the `app` folder. - Converted the `index.tsx `to `page.tsx` file as part of the App Router. - Created `layout.tsx` in app directory, merging functionality from both `_app.tsx` and `_document.tsx`: - Wraps content with `StyledComponentsRegistry` - Created `app/registry.tsx` for JSS setup: - Moved JSS Provider and SheetsRegistry from _document.tsx - Moved style cleanup logic from _app.tsx - Handles server-side style generation - Updated the package.json file. The following actions were performed as part of this PR: - Ran `pnpm prettier-check` with no issues found. - Executed the `pnpm check-examples` script. CC: @samcx --------- Co-authored-by: samcx <[email protected]>
## Why? It turns out the `react/self-closing-comp` rule is not necessary to cover for JSX tags that are not properly closed.
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 : )