chore(deps): batch #466 + #465 + #464; hold TypeScript 7 - #467
Merged
Merged
Conversation
…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.
This was referenced Sep 10, 2026
This was referenced Sep 12, 2026
Closed
This was referenced Sep 12, 2026
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
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.
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.
Two defects, same shape
Both are declarations that read correctly while the thing they described did not happen.
@types/react-domoverride outranked the bump. #466 raisedapps/{docs,landing,studio}to^19.2.7, butpnpm.overridesholds that package as an exact pin at19.2.5. Overrides apply to direct dependencies too, so the pin won and every lockfile importer still recordedspecifier: 19.2.5— three manifests claiming a version that was not installed.pnpm drift:checkcaught it, the second time that gate has paid for itself after thevite7-vs-8 incident it was built for. Raised in both places pnpm reads, plus the registry row indocs/{en,vi}/security/dependency-overrides.md, whose EN copy was itself stale at19.2.4.apps/docslost every Testing Library matcher type under vitest 5. It imported the bare@testing-library/jest-dom, which declares matchers on the globaljest.Matchersinterface. Vitest read that interface up to v4, sotoBeInTheDocumenttype-checked by accident; v5 stopped reading it. Result: 15 ×TS2339acrossLinkRewriter.test.tsxandanalytics-consent.test.tsx, failingtypecheckandbuildwhile the tests kept passing at runtime — the kind of break a green test run hides.apps/studioalready used the/vitestentry, 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 --noEmitis green 18/18, and in 8.5s against 2m9s on 5.9.3. Two tools refuse to run:typescript-eslint@8.70.0throwsError: typescript-eslint does not support TS 7.0.at require time → CI'sLint stable packagesfails forapps/{landing,consumer}.tsup --dtscrashes inrollup-plugin-dtsreadingts.sys.useCaseSensitiveFileNames, because TS 7 ships no programmatic API: its.entry is./lib/version.cjsandrequire('typescript')returns exactly two keys. That breaks the build of all six published packages, including the semver-frozen@lumibase/sdktypes.Proven DTS-specific rather than a tsup problem: the same tsup build without
--dtsfinishes in 80ms. Full analysis and the three ways forward are in backlog B63.The one piece of #417 worth keeping landed here:
baseUrlis gone from theapps/docsandapps/studiotsconfigs. 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:allclean — includingdrift:check(20 declarations vs 16 overrides) andsettings:checktypecheck18/18 ·build11/11 ·lint6/6RUN v5.0.0with zero cache hits: cms 2689 passed / 101 skipped, studio 383, docs 157verify:worker-bundle5.40 MB, none of the 5 Docker-only markers;verify:worker-startupboots under workerd — both re-run becausebullmqmoved 6.3.1→6.3.4 (B40)build:nodeemitsserve.cjs;@lumibase/runtime/dockerimports under Node with no top-level throw on bullmq 6.3.4docs:i18n:detect148/148 up-to-dateapps/landinghas 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 acceptedoverflow-x: clipstate, not a regression.vitest 5's sharper edges are all absent from this repo, checked before running: no
test.sequential, novi.mocknested inside a block, notoThrow(''), no unawaited.resolves/.rejects, and no test relying on mock call history surviving across tests (the newclearMocks: truedefault).Out-of-scope findings (DoD §7)
@tauri-apps/plugin-*npm deps inapps/shellcannot affect anything: that app has no JS/TS source, and grepping@tauri-apps/pluginacrossapps/andpackages/returns nothing. The plugins are used only from Rust; the versions that matter live inCargo.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.