fix(deps): update all non-major dependencies - #1595
Conversation
18e2ad0 to
e891041
Compare
DavidCockerill
left a comment
DavidCockerill
left a comment
There was a problem hiding this comment.
Requesting changes — this needs a code fix rather than a rebase, and there's a security bump inside it that shouldn't wait on that.
The batch isn't validated. Verify PR fails at Type-check, so none of the other 41 bumps were exercised. axios 1.18.1 → 1.19.0 breaks TypedAxios extends Axios — TS2430 at src/config/typedAxios.ts:5; axios widened the generic parameters on its public declarations so the interface extension no longer satisfies the base. renovate/artifacts is also failing.
There's an unremarked security release in here — Node 24.18.1, 11 CVEs, 3 High. Details in the thread; it's currently gated behind an unrelated axios type error, which is the wrong dependency.
Two further axios 1.19.0 changes are runtime-affecting rather than dev-only, worth checking once it compiles: sync request-interceptor dispatch semantics changed (axios#11071 — we install interceptors in installApiUnauthorizedRedirect.ts and getInstanceClient.ts), and repeated trailing slashes are now stripped when combining baseURL (axios#11038 — useEntityRestURL.ts massages baseURL itself). @datadog/browser-rum 7.6.1 → 7.7.0 also ships to browsers.
The good news: no stealth majors (nothing on a 0.x line) and no range widening — 40 of 42 are lockfile-only inside existing carets, with only the harper exact pin and packageManager moving in package.json. And axios raising the form-data floor for GHSA-hmw2-7cc7-3qxx is already covered by the form-data ^4.0.6 override.
Minor and unrelated: e2e/package.json moves packageManager to pnpm 11.19.0 while e2e/Dockerfile still pre-bakes corepack prepare pnpm@11.13.1, which defeats that image's reproducibility intent.
— Reviewed by DAIvid (Claude Opus 5)
| @@ -1 +1 @@ | |||
| 24.18.0 | |||
| 24.18.1 | |||
There was a problem hiding this comment.
Worth splitting this one out rather than letting it sit behind the axios break.
Node 24.18.0 → 24.18.1 (here and in e2e/Dockerfile) is an upstream security release — 11 CVEs, 3 High: CVE-2026-56846 and CVE-2026-56848 (http2), CVE-2026-58043 (permission model), plus an undici bump to 7.29.0. Renovate labels it a plain "patch", so nothing in the PR surfaces that.
As batched it can't land until typedAxios.ts is fixed. A standalone PR for the Node pin would land today.
There was a problem hiding this comment.
Still open at 8596d319, and the case for splitting got stronger.
The bump is no longer the 24.18.1 patch I commented on — renovate re-resolved it to 24.19.0, which its own body table labels minor. typedAxios.ts is untouched and Verify PR still fails on the same single TS2430, so the Node change is still hostage to axios two days on. GitHub has also marked this thread outdated, because renovate rewrote the line it was anchored to.
And e2e/Dockerfile did not follow — it went to 24.18.1-bookworm while this file says 24.19.0. Separate thread there.
A three-line PR setting .nvmrc, the Dockerfile FROM and its leading comment to one version would go green immediately and bank the security content.
There was a problem hiding this comment.
Still open at d55f5ba1, third round, and GitHub has now marked this thread outdated a second time for the same reason — renovate rewrote the line it was anchored to. That is the argument in miniature.
Nothing moved: .nvmrc is still 24.19.0, Verify PR still dies on the byte-identical TS2430 in src/config/typedAxios.ts, and that file has not been touched since cc6cd0a2 (2025-12-09). What did move is the batch — 5 files → 13, now including all six deploy workflows and e2e/pnpm-lock.yaml.
So the Node security content has sat behind an unrelated TypeScript error for three days while the thing it is batched with kept growing. A standalone PR for the pins (.nvmrc, the Dockerfile FROM, its corepack prepare pnpm@…, and the stale comment on line 1) is four lines with no lockfile and would go green on the first run.
95f7d7a to
e11fbea
Compare
kriszyp
left a comment
kriszyp
left a comment
There was a problem hiding this comment.
🤖 Dispatch codex review (verdict COMMENTS).
🤖 Reviewed with Codex
| "typescript": "~7.0.0" | ||
| }, | ||
| "packageManager": "pnpm@11.13.1" | ||
| "packageManager": "pnpm@11.19.0" |
There was a problem hiding this comment.
Please update e2e/Dockerfile alongside this pin. It still explicitly prepares pnpm 11.13.1, while this manifest now requests 11.19.0. Corepack will normally honor the nearest packageManager field, but that makes the image prepare/cache one version and then acquire another, undermining the stated reproducibility and adding avoidable setup. The Dockerfile’s first-line Node comment is also still pinned to 24.18.0 after this PR changes the image to 24.18.1.
— KrAIs (Codex)
37199ee to
8596d31
Compare
DavidCockerill
left a comment
DavidCockerill
left a comment
There was a problem hiding this comment.
Re-reviewed at 8596d319. Block stands, and Verify PR is a real break — a rebase won't clear it.
Install dependencies passes on pnpm 11.19.0, so the lockfile resolves cleanly and peer deps are fine. The job then dies at Type-check on one error:
src/config/typedAxios.ts(5,18): error TS2430: Interface 'TypedAxios' incorrectly extends interface 'Axios'.
Cause, confirmed by installing both versions side by side: axios 1.18.1 declares AxiosRequestConfig<D = any> with params?: any; 1.19.0 declares AxiosRequestConfig<D = any, P = any> with params?: P. That any was what let TypedAxios's narrowed overrides pass bivariant parameter checking — with a real type parameter that direction fails, and TS reports the residual mismatch on data.
I tried three shapes under tsc --strict against 1.19.0: threading axios' new P through still fails, dropping the data?: B narrowing still fails, and extends Omit<Axios, 'get'|'delete'|'head'|'options'|'post'|'put'|'patch'|'postForm'|'putForm'|'patchForm'> passes — including the axios.create(...) as TypedAxios cast at src/config/apiClient.ts:11, and with call sites still resolving the generated paths response type. (Caveat: my repro used a synthetic paths type, not the real generated one.)
Worth knowing what this costs: unit tests, lint and Build are all skipped after the type-check failure, so none of the other 168 changed lockfile entries has been validated on this head. renovate/artifacts is separately red, unchanged from last round.
One thing I checked because it looked like a collision and isn't: axios 1.19.0 does not interact with #1598's RFC 9457 error handling. Nothing changed in response-body parsing, transformResponse, responseType, or how response.data is populated on a non-2xx or non-JSON response. The three error-adjacent items land elsewhere — error.message on an otherwise-empty AggregateError, Set serialization in AxiosError.toJSON(), and the params generic (declarations only). #1598's data.title/data.detail reads are safe either way, and there's no file overlap, so merge order doesn't matter.
No hidden majors. Two pre-1.0 packages take semver-breaking steps (@oxc-project/types under oxlint, @datadog/js-core under browser-rum), both transitive and dev/vendor-internal. Worth a look once CI can actually run: vite 8.2.0 dragging rolldown 1.1.5→1.2.2 and dropping the wasm fallback binding, with Build never executed.
Recommendation, same as last round but stronger: split the Node pin out. Details in the threads.
Reviewed by Claude Opus 5 for @DavidCockerill.
| # screenshot baselines are stable and reproducible (generate baselines HERE, not | ||
| # on macOS). Multi-arch base — builds natively on Apple Silicon (arm64). | ||
| FROM node:24.18.0-bookworm | ||
| FROM node:24.18.1-bookworm |
There was a problem hiding this comment.
The two Node pins now disagree. This goes to 24.18.1-bookworm, but .nvmrc in the same commit goes to 24.19.0 — renovate lists them as separate entries from two datasources (node-version → minor, docker → patch, with Pending: 24.19.0 on this one).
Merged as-is, the e2e image runs a different Node than local dev and CI, for no reason anybody chose. Worth landing them on the same version.
(The stale pnpm@11.13.1 on line 7 and the stale 24.18.0 in the line-1 comment are already covered by @kriszyp's thread on e2e/package.json:29 — not repeating those, but the same one-line pass fixes all four.)
01780d9 to
3625271
Compare
dawsontoth
left a comment
dawsontoth
left a comment
There was a problem hiding this comment.
Re-confirming the block on the current head 3625271d — the rebase since 8596d319 did not clear it, and the diagnosis above still holds exactly.
Local verification with Node 24.18.0, pnpm 11.20.0: pnpm install --frozen-lockfile clean, tsc -b --force fails with the same single error:
src/config/typedAxios.ts(5,18): error TS2430: Interface 'TypedAxios' incorrectly extends interface 'Axios'.
What I can add: the rest of the batch is clean. The open question through the last two rounds has been that CI stops at Type-check, so none of the other bumps have ever been exercised. I ran the batch locally with only axios reverted to 1.18.1 and everything else left at this head:
tsc -b --force→ exit 0vitest run→ 281/281 test files, 2145 passed | 11 skipped
And with axios back at 1.19.0, the test suite still passes 281/281 — the failure is confined to the type layer. So axios is the sole blocker in a 42-package batch, and the split you recommended is now backed by a green run rather than an assumption. That also means the Node 24.18.1 security pin and the @datadog/browser-rum bump are being gated by one unrelated type error, which is the wrong shape.
Mechanism, confirmed by diffing the two declaration files side by side — it's an arity change, not just a widening:
1.18.1: get<T = any, R = AxiosResponse<T>, D = any>(...)
export interface AxiosRequestConfig<D = any>
1.19.0: get<T = any, R = AxiosResponseDefault, D = any, P = any>(...): Promise<AxiosResponseResult<T, R, D, P>>
export interface AxiosRequestConfig<D = any, P = any>
TypedAxios's overrides declare three type parameters (Q, U, R) against a base that now declares four, so TS's positional pairing slides — the error text shows studio's Q being instantiated as the base's P, landing AxiosRequestConfig<D, P> against TypedAxiosRequestConfig<P, never> and failing on data. That's also why the two obvious minimal fixes don't work: I tried TypedAxiosRequestConfig<Q, B> extends AxiosRequestConfig<B, Q> (threading the query type into axios' new P slot, which reads like the semantically right move since P is the params generic) and it produces the identical error. Consistent with the three shapes already tried above — the extends Omit<Axios, ...> approach looks like the one that actually sidesteps the pairing problem, since it stops asking TS to reconcile the two signatures at all.
Not something Renovate can resolve on its own: this needs the typedAxios.ts migration as its own PR, with axios held out of the non-major group until it lands.
3625271 to
d55f5ba
Compare
DavidCockerill
left a comment
DavidCockerill
left a comment
There was a problem hiding this comment.
Round 3 at d55f5ba1. Nothing that mattered changed — but what did change strengthens the case for splitting.
src/config/typedAxios.ts isn't in the diff at all; last touched cc6cd0a2, 2025-12-09. So Verify PR still dies at Type-check on the byte-identical TS2430, and unit tests, lint and Build are all still skipped — leaving all 187 changed package entries unvalidated for a third round. axios is unchanged at 1.18.1 → 1.19.0 and still in the batch.
Recapping the cause once, since it's the whole blocker: axios 1.18.1 declares AxiosRequestConfig<D = any> with params?: any; 1.19.0 declares AxiosRequestConfig<D = any, P = any> with params?: P. The any is what let TypedAxios's narrowed overrides pass bivariant parameter checking. I tested three shapes under tsc --strict against 1.19.0: threading axios' new P through fails, dropping the data?: B narrowing fails, and extends Omit<Axios, 'get'|'delete'|'head'|'options'|'post'|'put'|'patch'|'postForm'|'putForm'|'patchForm'> passes — including the axios.create(...) as TypedAxios cast at src/config/apiClient.ts:11.
Three things are new, and all three argue the same way:
- The batch grew 5 → 13 files, adding seven GitHub Actions workflows — including all six deploy workflows — for
pnpm/action-setupv6.0.9 → v6.0.10. I dereferenced the annotated tag and the pinned SHA is genuine, so that one's verified clean. e2e/pnpm-lock.yamljoined, carryingplaywright 1.61.1 → 1.62.1. The e2e Dockerfile's own comment ties system deps to the resolved Playwright version "so screenshot baselines are stable and reproducible" — and there is no e2e workflow in.github/workflows/, so no CI job will ever exercise it.- Renovate half-applied @kriszyp's corepack fix:
e2e/package.jsonwent topnpm@11.20.0whilee2e/Dockerfile:7still prepares11.13.1. A reviewer's fix produced a second pin mismatch. Thread below.
The Node pins still disagree at exactly the same two values — .nvmrc 24.19.0 vs e2e/Dockerfile 24.18.1-bookworm — and my .nvmrc thread has now been marked outdated a second time, because renovate rewrote the line it was anchored to. Per-line review doesn't durably hold a finding on this PR, which is itself part of the argument.
One improvement: renovate/artifacts, red in rounds 1 and 2, is green now. No majors anywhere across 187 entries; three pre-1.0 transitives take semver-breaking steps, all dev-only or Radix-internal. No react, react-dom, react-query, typescript, or auth/crypto library in the batch.
Recommendation, third time and now empirical rather than stylistic: split the four runtime-pin lines — .nvmrc, the Dockerfile FROM, its corepack prepare pnpm@…, and its stale leading comment. Four lines, no lockfile, green on the first run, and it banks Node security content that has been stuck behind a TypeScript error in an unrelated file since 2026-08-04. Optionally split axios out too, so the ~185 bulk bumps can land on a green build — the difference between one blocked PR and one blocked line.
Reviewed by Claude Opus 5 for @DavidCockerill.
| FROM node:24.18.0-bookworm | ||
| FROM node:24.18.1-bookworm | ||
|
|
||
| RUN corepack enable && corepack prepare pnpm@11.13.1 --activate |
There was a problem hiding this comment.
This is the other half of @kriszyp's #discussion_r3720046292 — and renovate applying only one side has made the gap wider, not narrower.
e2e/package.json moved to pnpm@11.20.0 in this same commit; this line still prepares 11.13.1. Corepack honours the nearest packageManager field, so the baked version is dead weight at best and a fetch-at-runtime — or a failure in an offline build — at worst, which is exactly the point kriszyp raised.
While this line is being fixed, two more in the same window are stale:
- line 1 still says
Node pinned to the repo's .nvmrc (24.18.0)— wrong against both theFROM(24.18.1) and.nvmrc(24.19.0) - line 5, the Node divergence, is
#discussion_r3729774054
All four are the standalone-PR candidate described on .nvmrc. Credit to kriszyp for catching the corepack half first.
d55f5ba to
750560f
Compare
750560f to
18ea117
Compare
renovate
Bot
changed the title
|
3 participants
This PR contains the following updates:
4.0.40→4.0.554.0.61(+4)7.6.1→7.7.07.8.07.6.1→7.7.07.8.05.21.2→5.22.01.2.2→1.2.31.11.0→1.12.15.4.0→5.7.11.61.1→1.62.11.2.18→1.2.201.1.21→1.1.232.3.5→2.3.71.1.21→1.1.232.1.22→2.1.242.1.13→2.1.151.2.20→1.2.221.4.5→1.4.71.2.16→1.2.182.3.5→2.3.71.1.13→1.1.151.3.1→1.3.31.3.5→1.3.71.1.19→1.1.211.1.16→1.1.181.2.14→1.2.169.12.0→9.13.01.170.18→1.170.191.170.23(+3)1.167.0→1.167.119.2.17→19.2.1819.2.3→19.2.46.0.4→6.0.57.0.37→7.0.527.0.58(+4)1.18.1→1.19.01.10.12→1.11.35.1.23→5.2.05.2.11.26.0→1.28.01.30.0(+1)11.16.0→11.16.112.42.2→12.43.024.18.0→24.19.024.18.0-bookworm→24.18.1-bookworm24.19.01.75.0→1.77.011.17.0→11.20.011.13.1→11.20.0v6.0.9→v6.0.1019.1.1→19.3.07.82.0→7.84.03.10.0→3.10.15.32.11→5.32.128.1.5→8.2.08.2.1Release Notes
vercel/ai (@ai-sdk/react)
v4.0.55Compare Source
Patch Changes
3836a85]1bec07d]v4.0.54Compare Source
Patch Changes
160ccdb]v4.0.53Compare Source
Patch Changes
79e133c]da64b51]v4.0.52Compare Source
Patch Changes
v4.0.51Compare Source
Patch Changes
v4.0.50Compare Source
Patch Changes
5fc7da5]93b2acd]v4.0.49Compare Source
Patch Changes
v4.0.48Compare Source
Patch Changes
d6ce0ee]fa95504]349afe7]v4.0.47Compare Source
Patch Changes
015acb4]v4.0.46Compare Source
Patch Changes
d8210b6]b192878]97f0565]v4.0.45Compare Source
Patch Changes
1659cd5]60f97f6]6a5bdff]6de2ec1]v4.0.44Compare Source
Patch Changes
2e2224b]v4.0.43Compare Source
Patch Changes
c3782a6]v4.0.42Compare Source
Patch Changes
0c464d9]09a52cb]c49380c]v4.0.41Compare Source
Patch Changes
7bd6bdd]1e2f324]DataDog/browser-sdk (@datadog/browser-rum)
v7.7.0Compare Source
Public Changes:
Internal Changes:
DataDog/datadog-ci (@datadog/datadog-ci)
v5.22.0Compare Source
What's Changed
datadog-ci
ci.pipeline.display_nametag for Buildkite by @gbrandrea in #2412Documentation
RUM
--debug-idupload mode for web sourcemaps by @amortemousque in #2374Serverless
Source Code Integration
Chores
New Contributors
Full Changelog: DataDog/datadog-ci@v5.21.2...v5.22.0
HarperFast/agent-tools (@harperfast/agent-tools)
v1.2.3Compare Source
Bug Fixes
Dependency Updates
HarperFast/skills (@harperfast/skills)
v1.12.1Compare Source
Documentation
3749d0c(#70) (72d2e99)v1.12.0Compare Source
Features
v1.11.1Compare Source
Bug Fixes
react-hook-form/resolvers (@hookform/resolvers)
v5.7.1Compare Source
v5.7.0Compare Source
Features
v5.6.0Compare Source
v5.5.8Compare Source
Bug Fixes
v5.5.7Compare Source
v5.5.6Compare Source
v5.5.5Compare Source
Bug Fixes
v5.5.4Compare Source
Bug Fixes
v5.5.3Compare Source
Bug Fixes
v5.5.2Compare Source
v5.5.1Compare Source
Bug Fixes
v5.5.0Compare Source
Features
v5.4.3Compare Source
Bug Fixes
v5.4.2Compare Source
Bug Fixes
a21e723)b7bb3f9)v5.4.1Compare Source
Bug Fixes
microsoft/playwright (@playwright/test)
v1.62.1Compare Source
v1.62.0Compare Source
🧱 New component testing model
Component testing moves to a stories and galleries model.
A story wraps your component in one specific scenario — hard-coded props, mock data, providers — and a
gallery page that you serve renders stories on demand. The new fixtures.mount() fixture navigates
to the gallery, mounts a story by id, and returns a Locator scoped to the story's root element:
Pass a story type as a template argument to type-check its props, and use
update(props)/unmount()on the returned locator to re-render or tear down within a test.🛑 Cancel operations with AbortSignal
Most operations and web-first assertions now accept a
signaloption that takes anAbortSignal, letting youcancel long-running actions, navigations, waits, and assertions:
Providing a signal does not disable the default timeout; pass
timeout: 0to disable it.🖼️ WebP screenshots
expect(page).toHaveScreenshot() and expect(locator).toHaveScreenshot()
can now store snapshots in the WebP format — just give the snapshot a
.webpname:page.screenshot() and locator.screenshot() also accept
webpas atype,where quality
100(the default) is lossless and lower values use lossy compression.🧩 Custom test filtering with Reporter.preprocess()
New reporter.preprocess() hook runs after the configuration is resolved and before
reporter.onBegin(), letting a reporter mark individual tests as skipped, excluded,
fixed, or failing through a TestRun object:
🔁 Isolated retries
New testConfig.retryStrategy controls when failed tests are retried. The default
'immediate'retries as soon as a worker is free;'isolated'runs all retries at the end,one by one in a single worker, to minimize interference with the rest of the suite:
New APIs
Browser and Context
credentialsincludes the context's virtual WebAuthn Credentials (passkeys) in the storage state, so they can be persisted and re-seeded into later contexts.Actions
scrolloption ("auto"|"none") on actions to opt out of Playwright's automatic scroll-into-view.Network
Evaluation
Command line & MCP
playwright-cli, runnable vianpx playwright mcpandnpx playwright cli.Reporters
mergeFilesreporter option:Announcements
Browser Versions
This version was also tested against the following stable channels:
radix-ui/primitives (@radix-ui/react-accordion)
v1.2.20@radix-ui/react-collapsible@1.1.20,@radix-ui/react-collection@1.1.15,@radix-ui/react-compose-refs@1.1.5,@radix-ui/react-context@1.2.2,@radix-ui/react-direction@1.1.4,@radix-ui/react-id@1.1.4,@radix-ui/react-primitive@2.1.10,@radix-ui/react-use-controllable-state@1.2.6v1.2.19@radix-ui/react-collection@1.1.14,@radix-ui/react-primitive@2.1.9,@radix-ui/react-collapsible@1.1.19radix-ui/primitives (@radix-ui/react-alert-dialog)
v1.1.23@radix-ui/react-compose-refs@1.1.5,@radix-ui/react-context@1.2.2,@radix-ui/react-dialog@1.1.23,@radix-ui/react-primitive@2.1.10v1.1.22@radix-ui/react-dialog@1.1.22,@radix-ui/react-primitive@2.1.9radix-ui/primitives (@radix-ui/react-context-menu)
v2.3.7@radix-ui/react-context@1.2.2,@radix-ui/react-menu@2.1.24,@radix-ui/react-primitive@2.1.10,@radix-ui/react-use-controllable-state@1.2.6v2.3.6@radix-ui/react-menu@2.1.23,@radix-ui/react-primitive@2.1.9radix-ui/primitives (@radix-ui/react-dialog)
v1.1.23@radix-ui/react-compose-refs@1.1.5,@radix-ui/react-context@1.2.2,@radix-ui/react-dismissable-layer@1.1.19,@radix-ui/react-focus-guards@1.1.6,@radix-ui/react-focus-scope@1.1.16,@radix-ui/react-id@1.1.4,@radix-ui/react-portal@1.1.17,@radix-ui/react-presence@1.1.10,@radix-ui/react-primitive@2.1.10,@radix-ui/react-slot@1.3.3,@radix-ui/react-use-controllable-state@1.2.6,@radix-ui/react-use-layout-effect@1.1.4v1.1.22@radix-ui/react-slot@1.3.2,@radix-ui/react-primitive@2.1.9,@radix-ui/react-dismissable-layer@1.1.18,@radix-ui/react-focus-scope@1.1.15,@radix-ui/react-portal@1.1.16radix-ui/primitives (@radix-ui/react-dropdown-menu)
v2.1.24@radix-ui/react-compose-refs@1.1.5,@radix-ui/react-context@1.2.2,@radix-ui/react-id@1.1.4,@radix-ui/react-menu@2.1.24,@radix-ui/react-primitive@2.1.10,@radix-ui/react-use-controllable-state@1.2.6v2.1.23@radix-ui/react-menu@2.1.23,@radix-ui/react-primitive@2.1.9radix-ui/primitives (@radix-ui/react-label)
v2.1.15@radix-ui/react-primitive@2.1.10v2.1.14@radix-ui/react-primitive@2.1.9radix-ui/primitives (@radix-ui/react-navigation-menu)
v1.2.22@radix-ui/react-collection@1.1.15,@radix-ui/react-compose-refs@1.1.5,@radix-ui/react-context@1.2.2,@radix-ui/react-direction@1.1.4,@radix-ui/react-dismissable-layer@1.1.19,@radix-ui/react-id@1.1.4,@radix-ui/react-presence@1.1.10,@radix-ui/react-primitive@2.1.10,@radix-ui/react-use-callback-ref@1.1.4,@radix-ui/react-use-controllable-state@1.2.6,@radix-ui/react-use-layout-effect@1.1.4,@radix-ui/react-use-previous@1.1.4,@radix-ui/react-visually-hidden@1.2.11v1.2.21@radix-ui/react-collection@1.1.14,@radix-ui/react-primitive@2.1.9,@radix-ui/react-dismissable-layer@1.1.18,@radix-ui/react-visually-hidden@1.2.10radix-ui/primitives (@radix-ui/react-radio-group)
v1.4.7@radix-ui/react-compose-refs@1.1.5,@radix-ui/react-context@1.2.2,@radix-ui/react-direction@1.1.4,@radix-ui/react-presence@1.1.10,@radix-ui/react-primitive@2.1.10,@radix-ui/react-roving-focus@1.1.19,@radix-ui/react-use-controllable-state@1.2.6, `@radix-ui/react-use-sConfiguration
📅 Schedule: (in timezone America/New_York)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR was generated by Mend Renovate. View the repository job log.