Skip to content

chore(deps): batch #466 + #465 + #464; hold TypeScript 7 - #467

Merged
khuepm merged 3 commits into
mainfrom
chore/deps-batch-2026-09
Sep 13, 2026
Merged

khuepm merged 3 commits into
mainfrom
chore/deps-batch-2026-09

Conversation

@khuepm

@khuepm khuepm commented Sep 10, 2026

Copy link
Copy Markdown
Owner

Consolidates three of the four open dependabot PRs and explains why the fourth stays closed. They share one lockfile, so they cannot be verified apart.

PR Verdict
#466 minor-and-patch group (27 updates) absorbed — needed a fix, see below
#465 vitest 4.1.11 → 5.0.0 absorbed — needed a fix, see below
#464 framer-motion 12.43 → 13.2 absorbed — clean
#417 typescript 5.9.3 → 7.0.2 not merged — blocked upstream, tracked as B63

Two defects, same shape

Both are declarations that read correctly while the thing they described did not happen.

@types/react-dom override outranked the bump. #466 raised apps/{docs,landing,studio} to ^19.2.7, but pnpm.overrides holds that package as an exact pin at 19.2.5. Overrides apply to direct dependencies too, so the pin won and every lockfile importer still recorded specifier: 19.2.5 — three manifests claiming a version that was not installed. pnpm drift:check caught it, the second time that gate has paid for itself after the vite 7-vs-8 incident it was built for. Raised in both places pnpm reads, plus the registry row in docs/{en,vi}/security/dependency-overrides.md, whose EN copy was itself stale at 19.2.4.

apps/docs lost every Testing Library matcher type under vitest 5. It imported the bare @testing-library/jest-dom, which declares matchers on the global jest.Matchers interface. Vitest read that interface up to v4, so toBeInTheDocument type-checked by accident; v5 stopped reading it. Result: 15 × TS2339 across LinkRewriter.test.tsx and analytics-consent.test.tsx, failing typecheck and build while the tests kept passing at runtime — the kind of break a green test run hides. apps/studio already used the /vitest entry, which is exactly why only one of the two jsdom apps broke. Now in step.

Why #417 is not here

TypeScript 7's native compiler works on this codebase — tsc --noEmit is green 18/18, and in 8.5s against 2m9s on 5.9.3. Two tools refuse to run:

  • typescript-eslint@8.70.0 throws Error: typescript-eslint does not support TS 7.0. at require time → CI's Lint stable packages fails for apps/{landing,consumer}.
  • tsup --dts crashes in rollup-plugin-dts reading ts.sys.useCaseSensitiveFileNames, because TS 7 ships no programmatic API: its . entry is ./lib/version.cjs and require('typescript') returns exactly two keys. That breaks the build of all six published packages, including the semver-frozen @lumibase/sdk types.

Proven DTS-specific rather than a tsup problem: the same tsup build without --dts finishes in 80ms. Full analysis and the three ways forward are in backlog B63.

The one piece of #417 worth keeping landed here: baseUrl is gone from the apps/docs and apps/studio tsconfigs. Both set it to ".", so it changes nothing today, and TS 7 removed the option (TS5102). Verified backward-compatible on 5.9.3.

Verification

  • check:all clean — including drift:check (20 declarations vs 16 overrides) and settings:check
  • typecheck 18/18 · build 11/11 · lint 6/6
  • tests 14/14 on RUN v5.0.0 with zero cache hits: cms 2689 passed / 101 skipped, studio 383, docs 157
  • verify:worker-bundle 5.40 MB, none of the 5 Docker-only markers; verify:worker-startup boots under workerd — both re-run because bullmq moved 6.3.1→6.3.4 (B40)
  • build:node emits serve.cjs; @lumibase/runtime/docker imports under Node with no top-level throw on bullmq 6.3.4
  • docs i18n changed-pair parity gate: 1/1 pair, 0 problems; docs:i18n:detect 148/148 up-to-date

apps/landing has no component tests (B17), so framer-motion 13 was checked in a real browser over CDP instead of inferred: 1053 elements of which 96 carry Framer Motion's inline transform/opacity styles, no console errors, no uncaught exceptions — against a 12.43 baseline of 95 on the same tree. The 8px of horizontal overflow the probe reports is identical on both versions; it is B39's accepted overflow-x: clip state, not a regression.

vitest 5's sharper edges are all absent from this repo, checked before running: no test.sequential, no vi.mock nested inside a block, no toThrow(''), no unawaited .resolves/.rejects, and no test relying on mock call history surviving across tests (the new clearMocks: true default).

Out-of-scope findings (DoD §7)

  • B62 — the four @tauri-apps/plugin-* npm deps in apps/shell cannot affect anything: that app has no JS/TS source, and grepping @tauri-apps/plugin across apps/ and packages/ returns nothing. The plugins are used only from Rust; the versions that matter live in Cargo.lock (dialog 2.7.1, deep-link 2.4.9, updater 2.10.1) while chore(deps): bump the minor-and-patch group across 1 directory with 27 updates #466 raised the npm side to ^2.7.3/^2.4.10/^2.11.0.
  • B63 — the TypeScript 7 blocker pair above.

…pin with them

Three dependabot PRs land together because they share one lockfile: the
27-package minor/patch group (#466), vitest 4.1.11 -> 5.0.0 across the eleven
packages that run it (#465), and framer-motion 12.43 -> 13.2 for apps/landing
(#464). No public surface changes.

#466 needed a fix to be true. It raised apps/{docs,landing,studio} to
@types/react-dom ^19.2.7 but could not know about pnpm.overrides, where that
package is an exact pin at 19.2.5. Overrides apply to direct dependencies too,
so the pin won and every lockfile importer still recorded
`specifier: 19.2.5` — three manifests claiming a version that was not
installed. `pnpm drift:check` caught it; this is the second time that gate has
paid for itself after the vite 7-vs-8 incident it was built for. The pin is
raised in both places pnpm reads (package.json for pnpm 9,
pnpm-workspace.yaml for pnpm 10+), and the registry row in
docs/{en,vi}/security/dependency-overrides.md is corrected — its EN copy was
itself stale at 19.2.4.

Notable in the group: zod 4.4->4.6, next 16.3.3->16.3.4, hono 4.13.5->4.13.7,
wrangler 4.127->4.129, bullmq 6.3.1->6.3.4, lucide-react 1.34->1.41,
@types/node 26.4.0->26.4.1.

framer-motion 13's only breaking change is dropping @emotion/is-prop-valid as
an optional dependency; this workspace has no CSS-in-JS, so it cannot apply.
The vitest 5 changes that bite elsewhere are all absent here: no
test.sequential, no vi.mock nested inside a block, no toThrow(''), no
unawaited .resolves/.rejects, and no test relying on mock call history
surviving across tests (the new clearMocks: true default).

Verified: lockfile importers record 19.2.7 and typescript stays at 5.9.3;
check:all clean; typecheck 18/18; build 11/11; tests 14/14 on `RUN v5.0.0`
with zero cache hits (cms 2689 passed / 101 skipped, studio 383, docs 157);
verify:worker-bundle 5.40 MB with none of the 5 Docker-only markers and
verify:worker-startup boots under workerd, both re-checked because bullmq moved
(B40); build:node emits serve.cjs; `@lumibase/runtime/docker` imports under
Node without a top-level throw on bullmq 6.3.4.

framer-motion was checked in a real browser, not inferred, because apps/landing
has no component tests (B17): the built page renders 1053 elements of which 96
carry Framer Motion's inline transform/opacity styles, with no console errors
and no uncaught exceptions, against a 12.43 baseline of 95 on the same tree.
The 8px of horizontal overflow the probe reports is identical on both versions —
it is B39's accepted `overflow-x: clip` state, not a regression.
…he jest one

apps/docs imported the bare `@testing-library/jest-dom`, which declares its
matchers on the global `jest.Matchers` interface. Vitest read that interface up
to v4, so `toBeInTheDocument` and friends type-checked by accident. Vitest 5
stopped reading it — a library supporting both runners now has to augment
`jest.Matchers` and `vitest.Matchers` separately — so under v5 every matcher in
LinkRewriter.test.tsx and analytics-consent.test.tsx lost its type: fifteen
`TS2339: Property 'toBeInTheDocument' does not exist on type 'Assertion<void,
HTMLElement>'` errors that failed `typecheck` and `build` while the tests
themselves still passed at runtime.

apps/studio already imported `@testing-library/jest-dom/vitest`, which is the
whole reason only one of the two jsdom apps broke. This brings docs in step.

Also drop `baseUrl` from the apps/docs and apps/studio tsconfigs. Both set it to
`"."`, so removing it changes nothing today: `paths` without `baseUrl` resolve
relative to the tsconfig, which is that same directory, and Vite resolves `@/*`
from its own `resolve.alias` either way. TypeScript 7 removed the option
outright (TS5102), so this is groundwork, not a fix — the two lines were the
only thing standing between this workspace and a clean `tsc` run on the native
compiler.

Verified: docs typecheck, test (24 files / 157 tests) and build all pass on
vitest 5; workspace typecheck 18/18, build 11/11, lint 6/6 on typescript 5.9.3,
so the baseUrl removal is backward compatible and not a bet on 7.
…cope findings

CHANGELOG entry for the batch, including why TypeScript 7 is not part of it.

Two backlog rows (DoD §7), both found while verifying the batch and both outside
its scope:

- B62: the four `@tauri-apps/plugin-*` npm dependencies in apps/shell cannot
  affect anything. That app has no JS/TS source at all — its frontendDist is the
  apps/studio build — and grepping `@tauri-apps/plugin` across apps/ and
  packages/ returns nothing; the plugins are used only from Rust in
  src-tauri/src/lib.rs. The versions that matter live in Cargo.lock (dialog
  2.7.1, deep-link 2.4.9, updater 2.10.1) while #466 raised the npm side to
  ^2.7.3 / ^2.4.10 / ^2.11.0, so those numbers describe something that is never
  loaded — a declaration that reads correctly and means nothing, the same shape
  as B20/B31/B53.

- B63: TypeScript 7.0.2 is blocked upstream, not by this codebase. The native
  compiler typechecks all 18 packages here, and does it in 8.5s against 2m9s on
  5.9.3, but 7.0 ships without the programmatic compiler API: `require('typescript')`
  returns exactly two keys. `typescript-eslint` throws `does not support TS 7.0.`
  at require time, failing lint for apps/{landing,consumer}, and `tsup --dts`
  crashes in rollup-plugin-dts reading `ts.sys.useCaseSensitiveFileNames`, which
  breaks the build of all six published packages — including the semver-frozen
  `@lumibase/sdk` types. Proven DTS-specific: the same tsup build without --dts
  finishes in 80ms. The row records the three ways forward and notes that a stop
  on TS 6 to clear deprecations should come first.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant