Repository navigation
build(deps): consolidate the open dependabot updates - #1915
Merged
Merged
Conversation
This was referenced Aug 24, 2026
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
plumix-marketing | 7172da5 | Commit Preview URL Branch Preview URL |
Aug 24 2026, 04:33 PM |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
plumix-docs | 7172da5 | Commit Preview URL Branch Preview URL |
Aug 24 2026, 04:34 PM |
Supersedes the twelve individual Dependabot PRs (#1900-#1903, #1905-#1907, #1910-#1914) with one branch, so the shared lockfile is resolved once instead of twelve conflicting times. Also refreshes every other dependency within its declared range. Three bumps needed real migration rather than a version edit: - TanStack Table v8 -> v9: `useReactTable`/`getCoreRowModel` became `useTable` plus an explicit `tableFeatures` registry, and the public types grew a leading `TFeatures` generic. DataTable now owns that feature set and exports `DataTableColumnDef`, so callers keep naming one generic and the feature registry stays an implementation detail. Column meta moves from a global `declare module` augmentation to the per-table `columnMeta` slot. - markdown-it 15 bundles its own declarations, so `@types/markdown-it` is dropped; the instance type is now a named export separate from the callable default. - react-query 5.102 deprecated `ensureQueryData`/`fetchQuery` in favour of `query()`. Route loaders pass `staleTime: "static"` to keep the existing dedupe semantics. astro is held below 7.2.4 through an `@astrojs/markdown-satteri` cap: 7.2.4 moved to satteri 0.10 while starlight 0.41.7 (newest) still pins satteri ^0.9, and two copies break the docs typecheck. Lift the cap once starlight ships satteri 0.10 support.
Bumping the pin alone (as the Dependabot PR did) would have broken the first release after merge: v2 renamed every input and calls `throwOnRenamedInputs`, so `version`/`publish`/`commit`/`title` now hard-fail the step. - Renamed to `version-script`, `publish-script`, `commit-message`, `pr-title`. - v2 no longer reads the `GITHUB_TOKEN` env var, so the App token moves to the `github-token` input; without it the action falls back to `github.token`, whose pushes don't trigger the required checks. - `push-with-git-cli: true` keeps v1's git-CLI push instead of v2's new GitHub-API default, so the existing `persist-credentials` setup still applies. - v2 dropped .npmrc handling, so the empty `NPM_TOKEN` workaround that kept OIDC trusted publishing reachable is no longer needed. Pinned to v2.1.1 rather than the v2.1.0 Dependabot proposed: 2.1.1 fixes a typo in the renamed-input guard that reported `commit-mesage`. The pin is also the commit SHA, not the annotated tag object SHA that the tag ref resolves to.
Post-review cleanup of the react-query and TanStack Table migrations. - Six route guards spread `sessionQueryOptions()` with the same `staleTime`; `session.ts` already owns that query, so `loadSession` belongs there. The other five `query()` sites each spread a different oRPC factory and stay inline. - `DataTableColumnDef` drops its `TValue` parameter: table-core types `CellData` as `unknown`, so the constraint and its default were both vacuous. - Drop the markdown-it instance annotation — `new MarkdownIt()` already infers it, so the aliased type import bought nothing. - Move the `getAllCells` rationale to the call site it explains, and cut comments that restated the code beneath them.
…ly binds Two defects from review, both in areas CI does not exercise. changesets/action v2 is only compatible with Changesets v3 — its README says so, and the mechanism is that v2 reads published packages from the file named by CHANGESETS_OUTPUT. @changesets/cli 2.31 never writes that file, so v2 would publish to npm and then skip every git tag and GitHub release, logging a warning rather than failing. The stuck tags would also make the release-detection step fire on every merge. Moving to CLI v3 changes how peer-dependent packages are bumped, which is what `onlyUpdatePeerDependentsWhenOutOfRange` is tuned around, so that pairing needs its own PR. Reverted to v1.9.0 with the constraint written down. The `@astrojs/markdown-satteri` override deduplicates satteri but does not pin astro, so the previous claim that it held astro below 7.2.4 was wrong — astro was sitting at 7.1.6 only because an earlier resolution left it there, and would float to 7.2.5 on the next update. Added the cap next to the existing starlight one. Both are needed: astro <7.2.4 alone still resolves two satteri copies, because astro 7.2.3 takes markdown-satteri as a range and picks 0.3.8. Together they land astro on 7.2.3, whose declared markdown-satteri is exactly the 0.3.6 the override yields — a supported pairing rather than a graft, and newer than 7.1.6.
The in-range lingui refresh to 6.6.0 broke the editor at runtime: opening an entry rendered "Couldn't open the editor" because the route loader threw `Cannot destructure property 'i18n' of ... as it is null` — useLingui() reading a context that was never populated. 6.6 made `@babel/core`/`@babel/types` optional peers of `@lingui/babel-plugin-lingui-macro`, accepting `^7.20 || ^8`. This workspace resolves both Babel majors, so pnpm built two peer-keyed `@lingui/react` instances and the code-split editor chunk got the one whose provider never mounted. main resolves a single `@lingui/react@6.4.0(react@19.2.8)`; this branch had 6.6.0 twice. Capped rather than fixed here: collapsing the workspace onto one Babel major is its own change with its own blast radius. A caret range would drift straight back onto 6.6, so the catalog pins `>=6.4.0 <6.5.0` — the same shape as the starlight and astro caps. Dependabot #1912 stays open. Found by e2e, which no local gate I had run covers. All nine suites now pass individually; running them concurrently contends for ports locally and is not a signal.
nasyrov
force-pushed
the
deps/consolidate-dependabot-updates
branch
from
August 24, 2026 16:30
429540d to
7172da5
Compare
nasyrov
added a commit
that referenced
this pull request
Aug 24, 2026
Closes the pairing #1915 deliberately left open, and supersedes #1901. `changesets/action` v2 only speaks to Changesets v3. It learns what got published by reading the file named by the `CHANGESETS_OUTPUT` env var it injects, and only the v3 CLI writes that file — pair v2 with a v2 CLI and the npm publish succeeds while every git tag and GitHub release is silently skipped, as a warning rather than a failure. So both move together, or neither. ## What changed - `@changesets/cli` 2.31 → **3.0.1**, `@changesets/changelog-github` 0.7 → **1.0.0** - `changesets/action` v1.9.0 → **v2.1.1**, with v2's renamed inputs (`version-script`, `publish-script`, `commit-message`, `pr-title`), the App token moved to the `github-token` input, and `push-with-git-cli: true` to keep v1's push behaviour instead of v2's new GitHub-API default - `.changeset/config.json`: `$schema` follows `@changesets/config` to v4, plus an explicit `format` (see below) - Root now carries `prettier` + `@plumix/prettier-config` ## Verification The release pipeline is the one thing PR CI cannot exercise, so I checked the semantics directly rather than relying on it going green. **Release plans are identical.** Ran `changeset status --output` under both 2.31.1 and 3.0.1 against the current 15 changesets: **22 releases, same bump types, same versions, zero differences.** **A real `changeset version` run touches only `version` fields** — no dependency or peer range is rewritten. That covers v3's headline change, that peer dependents now bump `patch` instead of `major`: `onlyUpdatePeerDependentsWhenOutOfRange` suppresses the in-range case, which is the only one a 0.x minor ever hits. The flag survives in `@changesets/config` v4 under the same experimental key. ## The one real break: formatting v3 dropped its bundled prettier in favour of formatter auto-detection, and prettier was **not resolvable from the repo root** — the root runs it per package through turbo. Generated changelogs came out unformatted (trailing whitespace on blank list lines, `*not*` instead of `_not_`) and **failed the format gate**, which would have blocked the Version PR on a required check. Fixed by giving the root `prettier` + the shared config, and naming `"format": "prettier"` rather than leaving `auto`. The failure modes differ and the explicit one is better: with `auto` and no resolvable prettier, changesets silently emits unformatted files that break a gate two steps later; naming prettier makes it fail loudly at version time instead. `prettier` is in knip's root `ignoreDependencies` — changesets shells out to `pnpm exec prettier`, so nothing imports it. ## Checked, not applicable No `prettier` config key to migrate to `format`. No `changeset tag` or `--sinceMaster` usage. No `publishConfig.registry` (v3 ignores those for pnpm). No prerelease state to migrate. `access` already `public`, `baseBranch` already explicit. Private packages stop being versioned by default in v3, but every private package here is already in `ignore`. `changeset version`'s new exit-1-when-no-changesets only fires when the action runs `version-script`, which it does only when changesets exist — I confirmed that branch in the action's bundle. Node 24.15 and pnpm 10.33 satisfy v3's new engines. ## Residual risk `release.yml` runs only on merge to main, so its first real exercise is the next release. The pieces above were each verified by hand, but the end-to-end publish path cannot be proven from a PR.
nasyrov
added a commit
that referenced
this pull request
Aug 24, 2026
… bundle (#1918) Lifts the `>=6.4.0 <6.5.0` lingui cap that #1915 added, and closes out the second follow-up from that PR. ## The stated plan doesn't work The follow-up was "collapse the workspace onto one Babel major." That isn't available. Three third-party packages take Babel 7 as a **hard `dependencies` entry** capped at `^7`: | Package | Declares | | --- | --- | | `@tanstack/router-plugin` | `@babel/core ^7.28.5`, `@babel/types ^7.28.5` | | `babel-dead-code-elimination` (via `@tanstack/router-utils`) | `@babel/core ^7.23.7` | | `eslint-plugin-react-hooks` | `@babel/core ^7.24.4` | Meanwhile admin's rolldown/vite pipeline supplies `@babel/core ^8.0.1`, and `@rolldown/plugin-babel` / `@lingui/vite-plugin` accept `^7.29 || ^8`. Forcing everything to 8 hands the three above a major they don't support; forcing 7 breaks admin's build pipeline. Both majors coexist by necessity, so pnpm keeps materializing one `@lingui/react` per peer context. ## What actually fixes it Two copies on disk is fine. Two copies **in one bundle** is not, because each carries its own `LinguiContext` — which is why `useLingui()` returned null and the editor rendered "Couldn't open the editor". `resolve.dedupe` in admin's Vite config is the right lever, and pins the bundle to a single copy. That's the whole change beyond the version bump. I tried a scoped `pnpm.overrides` on the macro's peers first (`@lingui/babel-plugin-lingui-macro>@babel/types`). **It does nothing** — the peer instance keys come from what each consumer provides down the graph, not from the macro's own declaration. Not shipped. ## Verification All **182** e2e tests pass across every suite that could see this — admin (129), admin-editor (33), and the six plugins (20) — run individually. The pages suite is the one that originally caught the regression. Plus typecheck, lint, format, test:unit, i18n, and knip (cold). ## Note on the remaining duplication The lockfile still carries two `@lingui/react` entries, and the whole Babel toolchain is still duplicated at 7.x and 8.x. That is upstream's shape, not something this repo can resolve today. It becomes fixable when `@tanstack/router-plugin` and `eslint-plugin-react-hooks` move to Babel 8 — at which point the `dedupe` entry can go.
nasyrov
added a commit
that referenced
this pull request
Aug 25, 2026
`@astrojs/starlight` goes back to a caret range, `>=0.41.5 <0.41.7` to
`^0.41.5`, resolving 0.41.8. The floor stays put — 0.41.4 and 0.41.5
carried
the `docsSchema({ extend })` fixes the frontmatter schema depends on.
**The upstream change #1865 was waiting for has not happened.**
Starlight
0.41.8 still declares `satteri: ^0.9.1` beside
`@astrojs/markdown-satteri: ^0.3.5`, so neither lift condition in the
issue is
met. The ceiling became redundant for an unrelated reason: the root
`pnpm.overrides` entry capping `@astrojs/markdown-satteri` below 0.3.7
landed
in #1915 and already holds the tree to one Sätteri copy, which is the
entire
job the ceiling was doing. Worth stating plainly, or the next reader
concludes
Starlight shipped a fix.
Verified by installing each configuration and type-checking it:
| Configuration | Sätteri copies | `pnpm typecheck` |
|---|---|---|
| Starlight 0.41.8, override present | 1 (`0.9.5`) | passes |
| Starlight 0.41.8, override removed | 2 (`0.9.5` + `0.10.5`) | TS2345 |
| Starlight 0.41.8, `astro` cap lifted | 1 (`0.9.5`) | passes |
### The README section is rewritten, not deleted
This departs from the issue's acceptance criteria, which say the
explanation
should be gone. Deleting it would leave the override undocumented — root
`package.json` cannot carry a comment, and that override is now the only
thing
keeping this app type-checking. The replacement covers all three ranges
that
constrain the tree and why none substitutes for another, including the
`astro`
cap, which until now was recorded nowhere but #1915's description.
The third row of the table is why that matters: lifting the `astro` cap
leaves
the typecheck green, so nothing in CI would catch its removal. It is
still
load-bearing — Astro declares `@astrojs/markdown-satteri` as an exact
version,
`0.3.6` at 7.2.3 rising to `0.3.8` by 7.2.6, and the wider that gap
grows
against the override's window, the further the tree drifts from a
pairing
Astro ships.
### Two things in #1865 need correcting when it closes
Its "Blocked by: Upstream" framing is wrong, per above — the issue
predates
#1915 and never mentions the override.
It also states that forcing `satteri` to 0.10.5 "surfaces a different
genuine
error in the same file." That configuration type-checks cleanly now. I
have
left the finding out of the README, because
`integrations/markdown-plugins.ts`
is byte-identical across 0.41.6, 0.41.7 and 0.41.8, so nothing Starlight
changed explains the reversal and I could not establish what does.
### Unrelated drift spotted, not fixed here
#1915 records that the override "yields exactly the `0.3.6` astro 7.2.3
declares — a supported pairing rather than a graft." The lockfile
resolves
`0.3.5`, and does so on `main` as well as on this branch, so it is not
introduced here. Possibly worth its own issue.
Fixes #1865
This was referenced Aug 25, 2026
nasyrov
added a commit
that referenced
this pull request
Aug 25, 2026
…1941) `@astrojs/markdown-satteri` moves 0.3.5 to 0.3.6 in the lockfile. `astro@7.2.3` declares that dependency as an exact `0.3.6`, so the tree had been carrying precisely the graft the root override exists to prevent — one patch below what Astro asks for. #1915 described the override as landing "a supported pairing rather than a graft"; now it actually does. Nothing had constrained it there. The override window `>=0.3.1 <0.3.7` always admitted 0.3.6, which published on 18 August; pnpm never re-resolved the entry and `--frozen-lockfile` preserved it. Both versions type-check and build, so no gate distinguished them — which is why this sat unnoticed. `@astrojs/markdown-satteri@0.3.6` carries no behaviour change of its own. Its changelog records one line, a bump of `@astrojs/internal-helpers` from `0.10.2` to `0.10.3`, and the lockfile diff is exactly that shape. ### On the diff being lockfile-shaped but not `pnpm update -r`-shaped The obvious command drags collateral: `pnpm update -r @astrojs/markdown-satteri` also bumps `prosemirror-view` 1.42.2 to 1.42.3, unrelated to any of this and the same family of trap as the cap-widening #1915 hit. Instead the override was pinned to an exact `0.3.6`, re-resolved with `--lockfile-only`, then restored to `>=0.3.1 <0.3.7` and re-resolved again. `package.json` therefore comes out byte-identical to `main` — both the `astro` cap and Starlight's floor stay exactly where they were. The lockfile's own `overrides` record and `@astrojs/mdx`'s recorded peer range both still read the restored window, so the temporary pin left nothing behind; `pnpm install --lockfile-only --frozen-lockfile` is a clean no-op, which pnpm would refuse if the two had diverged. What changed, in full: `markdown-satteri` 0.3.5 to 0.3.6, peer-key rewrites in `@astrojs/mdx` and `starlight-llms-txt`, and the removal of `@astrojs/internal-helpers@0.10.2` — dedup rather than loss, since 0.3.6 pins `0.10.3`, which the tree already carried, and nothing else referenced `0.10.2`. ### The README gains the failure mode An override window with slack keeps whichever version it resolved first, and nothing notices. That is the actual lesson here and it was recorded nowhere, so the docs README section covering this constraint cluster now says it. The tree is back on Astro's declared pairing either way; this is what stops the next reader re-deriving why it drifted. Fixes #1939
4 tasks
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Supersedes the open Dependabot PRs
This PR supersedes and replaces all twelve open Dependabot PRs. They all
touch
pnpm-lock.yaml, so merging them one at a time means eleven rebases andeleven lockfile re-resolutions. This resolves the lockfile once.
Close once this merges:
turbo,eslint-plugin-turbo→ ^2.10.11^8.2.1)@types/markdown-itdroppedEverything else was also refreshed within its declared range, so the tree is
current rather than just un-blocked.
Migrations the bumps required
Three bumps needed code changes, not a version edit.
TanStack Table v8 → v9 (#1907)
v9 replaces
useReactTable+getCoreRowModel()withuseTableplus anexplicit
tableFeaturesregistry, and every public type grew a leadingTFeaturesgeneric (ColumnDef<TData>→ColumnDef<TFeatures, TData, TValue>).DataTablenow owns that registry and exportsDataTableColumnDef<TData>, sothe three call sites keep naming a single generic and the feature set stays an
implementation detail of the component. Row selection is the only feature
registered; with column visibility off, cells come from
getAllCells()— theexact counterpart of the header's
getHeaderGroups().Column meta moved off the global
declare module "@tanstack/react-table"augmentation onto v9's per-table
columnMetaslot, which scopes it to thistable instead of every table in the process.
Two suppressions became dead and were removed: v9's store-backed instance is
React Compiler-compatible, so the
react-hooks/incompatible-librarydisable nolonger applies, and
datano longer needs areadonlycast.markdown-it 14 → 15 (#1913)
v15 bundles its own declarations, so
@types/markdown-itis removed — leavingit would shadow them. The instance type is now a named export separate from the
callable default, so the annotation imports
MarkdownIt as MarkdownItInstance.The comment-rendering security posture is unchanged:
linkify: falsemeansnone of the linkify-it v6 behavior changes apply, and the existing
javascript:-scheme andrel="nofollow ugc noopener"tests still pass.react-query 5.102
query()(in-range, via #1907's group)5.102 deprecates
ensureQueryDataandfetchQueryin favour ofquery(). Thetwelve call sites are migrated; route loaders pass
staleTime: "static"to keepensureQueryData's dedupe semantics.staleTimejoins the existing TanStackentries in the lingui
ignoreNameslist, since"static"is a sentinel and notuser copy.
changesets/action v1 → v2 (#1901) — deliberately NOT taken
This is the one Dependabot PR not folded in, and the reason is worth stating.
v2 is only compatible with Changesets v3 — its README says so directly. The
mechanism: v2 stopped scraping
New tag:out of the publish script's stdout andinstead reads published packages from a file named by a
CHANGESETS_OUTPUTenvvar it injects.
@changesets/cli2.31 contains zero references to that variable,so the file is never written.
The failure mode is the dangerous kind.
pnpm releasewould publish to npmnormally, then the action would find no output file, log a warning (not an
error), and report
published: false— so no git tags and no GitHub releases.Worse, the
Detect release workstep keys offgit rev-parse refs/tags/$name@$version,so with tags never pushed it would return
run=trueon every subsequent merge,doing a full cold build and no-op publish each time. Entirely green, silently broken.
Moving to
@changesets/cliv3 is the supported pairing, but v3 changes howpeer-dependent packages are bumped — precisely what
onlyUpdatePeerDependentsWhenOutOfRangein.changeset/config.jsonis tunedaround — plus it drops the
prettierconfig option and changes private-packageversioning. That is a release-pipeline design decision, not a dependency bump, so
it belongs in its own PR. #1901 should stay open.
The action stays at v1.9.0, with the constraint written into
release.ymlso thenext person doesn't rediscover it the hard way.
lingui 6.4 → 6.6 (#1912) — deliberately NOT taken
Also excluded, and this one was a live runtime break rather than a latent one.
6.6.0 makes the editor unopenable: the route loader throws
Cannot destructure property 'i18n' of ... as it is nulland the screen renders"Couldn't open the editor".
useLingui()is reading a context that was neverpopulated.
6.6 made
@babel/core/@babel/typesoptional peers of@lingui/babel-plugin-lingui-macro, accepting^7.20 || ^8. This workspaceresolves both Babel majors, so pnpm builds two peer-keyed
@lingui/reactinstances — two React contexts — and the code-split editor chunk gets the one
whose provider never mounted.
mainresolves a single@lingui/react@6.4.0(react@19.2.8); with 6.6 there are two.Taking 6.6 means collapsing the workspace onto one Babel major, which has its own
blast radius. The catalog pins
>=6.4.0 <6.5.0— a caret would drift straightback onto 6.6. #1912 should stay open.
astro is capped, in two places
apps/docscannot take astro 7.2.4+, which pins@astrojs/markdown-satteriat exactly
0.3.7→satteri ^0.10, while@astrojs/starlight(including0.41.7, the newest) still pins
satteri ^0.9. Twosattericopies in the treemake
astro checkfail with unrelated-identical-type errors inside starlight'sown
markdown-plugins.ts.Both constraints are required, and I verified each in isolation:
"@astrojs/markdown-satteri": ">=0.3.1 <0.3.7") dedupessatteri to one copy, but does not pin astro — pnpm overrides rewrite the
dependent's range rather than constraining resolution, so astro floats to 7.2.5
with an older markdown-satteri grafted underneath it.
markdown-satteri as a range, so pnpm picks 0.3.8 → satteri 0.10.
Together they land astro on 7.2.3, whose declared
@astrojs/markdown-satteriis exactly the
0.3.6the override yields — a supported pairing rather than agraft, and newer than the 7.1.6 the branch had been sitting on.
Lift both once starlight ships
satteri ^0.10support.Related:
pnpm updatesilently widens these caps. It rewrote the pre-existingstarlight >=0.41.5 <0.41.7cap to^0.41.7while this branch was being prepared,and later rewrote the new astro cap to
^7.2.3. Both were caught and restored.Verification
Every
ci.ymlgate run locally: commitlint, lint, format, typecheck, knip,i18n check + ratchet, publint, attw, test:unit, test:build, and a cold-cache full
build.
All nine e2e suites pass individually. Running them concurrently contends for
ports locally and is not a signal.
Three of the four problems in this PR were invisible to the gates I had been
running: the changesets and astro defects came from review (neither
release.ymlnor lockfile re-resolution is exercised by PR checks), and the lingui break was
caught only by e2e — typecheck, lint, and unit tests were all green while the
editor was unopenable.