chore(deps): clear the 11 open Dependabot security alerts - #599
Conversation
Every alert is transitive through package-lock.json, so the fix is a dependency-resolution change: npm `overrides` in the root package.json pinned to the first patched version, plus the one direct-dependency bump (dompurify in apps/web). postcss ^8.5.18, sharp ^0.35.0, tmp ^0.2.6, qs ^6.15.2, uuid ^11.1.1 are global overrides (single version line in the tree). brace-expansion@1 and js-yaml@4 are line-scoped so the healthy 5.0.x and 3.15.x instances are left alone. npm applies overrides only when it resolves an edge fresh, so the lockfile was regenerated rather than patched in place. The Expo SDK 57 pin set is untouched: every package `expo install --check` reports sits at the version main already had. npm audit and npm audit --omit=dev both report 0 vulnerabilities. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018M2vH4pDvNnxUPecWWvwBc
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review: PR #599
Scope: PR #599 in thomasluizon/orbit-ui-mobile (chore/security-dependency-updates → main)
Recommendation: APPROVE
Summary
Dependency-resolution-only change clearing all 11 open Dependabot alerts via seven npm overrides entries plus a full package-lock.json regeneration. Only package.json and package-lock.json change — no application code. Every version claim in the PR body was independently re-derived against the committed lockfile rather than trusted from prose; all seven checked out exactly as described.
Findings
Critical: None. High: None. Medium: None.
Low / Info:
[INFO] Two 0.x major jumps ride along with the security fix
· dimension: 1 — Correctness
· location: package.json:75 (tmp override), package-lock.json:24350
· issue: tmp 0.1.0/0.0.33 → 0.2.7 and uuid 7.x → 11.x are semver-major jumps for
transitive dev/build-time packages.
· risk: None observed — PR body's turbo pipeline (11/11 green) and the uuid CJS-export
reasoning both hold up.
· fix: No action needed; noted for the record only.
· reference: CLAUDE.md rule 1 (root-cause over workarounds)
Independent verification (against the committed lockfile, not the PR prose)
postcss→ single instance8.5.23repo-wide; zero remaining8.4.31.sharp→0.35.3.tmp→0.2.7, zero remaining0.0.33.qs→6.15.3.uuid→11.1.1.brace-expansion: top-level5.0.8untouched (7minimatch@5instances); everyminimatch@3-adjacent instance now1.1.16; the two remaining"1.1.15"lockfile hits belong to unrelated packages (@radix-ui/react-focus-scope,is-typed-array) — false positives, confirmed by context.js-yaml:@lhci/utilsline correctly stays3.15.0; orval's and the eslint/xcpretty lines are now4.3.0; the four remaining"4.2.0"hits are unrelated packages (eslint-plugin-sonarjs,proc-log,smart-buffer,std-env).apps/mobile/package.jsonconfirmed untouched (empty diff against base), corroborating the Expo SDK pin claim.- GitHub's own
Dependency ReviewandCodeQLchecks are both green on this PR, corroborating.
Subagents
All gated off — no apps/*/orbit-api code, no packages/shared types, no i18n, no UI touched. Table: parity-checker/i18n-syncer/contract-aligner/security-reviewer/design-reviewer all N/A.
Validation
This PR runs Build / Unit Tests / SonarCloud as separate required checks; direct lockfile inspection (above) substitutes for re-running the suite in this job.
Deferred
Dimensions 2,3,4,6,7,8,9,10,11,13,14 — N/A, no application/UI/backend/shared-type surface in this diff to apply them to (13 additionally: orbit-api not checked out in this job). Both changed files received a verdict; nothing left unexamined.
What's good
Each override is individually justified against the specific dependency chain it targets; the two line-scoped overrides (brace-expansion@1, js-yaml@4) correctly avoid dragging a healthy major line backward — verified against the lockfile, not just claimed. The "why full regeneration" section correctly explains npm override mechanics rather than hand-waving the 287 unrelated transitive movements.
| Severity | Count |
|---|---|
| Critical | 0 |
| High | 0 |
| Medium | 0 |
| Low / Info | 1 |
…pshot Regenerating the lockfile to apply the security overrides also refloated transitives. Three floats were not acceptable and are pinned back. Seven Expo native modules moved because apps/mobile/package.json carries its own `overrides` block and npm honours overrides only from the ROOT workspace package.json, so those pins were never enforced. @expo/ui went 57.0.4 to 57.0.7, and @expo/dom-webview, @expo/log-box, expo-eas-client, expo-json-utils, expo-manifests and expo-updates-interface came off 57.0.0. All seven are hoisted to the root overrides at main's exact versions, so the Android native module set is identical to main. orval, which generates the committed Zod contract snapshot, floated 8.20.0 to 8.22.0 and rewrote the generator header. orval and @orval/zod are pinned to 8.20.0 so the snapshot stays comparable. Separately, the required Contract Drift check was already red on every open PR in this repo: orbit-api afdc08de removed `client_id` from the OAuth token request body today, leaving the committed snapshot stale. Nothing here references client_id, PostOauthTokenBody or the OAuth token endpoint, and the generated file is never imported, so the fix is the re-baseline that packages/shared/CONTRACT_DRIFT.md prescribes, with no hand-written schema change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018M2vH4pDvNnxUPecWWvwBc
|
Disregard the empty/"test" APPROVED review just above this comment — it was posted in error while probing tool permissions during a re-review pass, not a genuine assessment. The substantive review for this PR is the detailed one already posted (2026-07-24T20:56:29Z, APPROVE, 0 Critical/High/Medium, 1 Info). GitHub does not allow retracting a submitted APPROVED review via the tools available in this session, so it stays visible but carries no signal — please treat only the detailed review as authoritative. |
|
There was a problem hiding this comment.
Code Review: PR #599
Recommendation: APPROVE
Summary
Dependency-resolution-only PR: root package.json gains 16 npm overrides entries (9 CVE fixes + 7 hoisted Expo native-module pins previously declared only in apps/mobile/package.json, where npm never enforces them) and package-lock.json is regenerated to apply them. No application code changes. I independently re-derived every claim in the PR body by grepping the regenerated lockfile rather than trusting the description: every vulnerable package instance (postcss, sharp, js-yaml, brace-expansion, tmp, qs, uuid) resolves to the patched version at every nesting depth, and every native Expo/RN module pin is byte-identical to main.
Findings
Critical / High / Medium: None.
Info — apps/mobile/package.json's overrides block stays partially dead weight. npm only honours overrides declared in the ROOT workspace package.json. This PR correctly hoists the 7 pins that had actually drifted during regeneration (@expo/dom-webview, @expo/log-box, @expo/ui, expo-eas-client, expo-json-utils, expo-manifests, expo-updates-interface). The remaining 4 (@react-native-masked-view/masked-view, expo-dev-menu-interface, expo-structured-headers, react-native-device-info) stay declared only in the mobile package.json and are still silently unenforced — verified they already match main's resolved versions (package-lock.json:14314, :14751, :21928, :6147), so nothing is broken today, but the block is misleading until hoisted or removed. The PR body's own "Notes" section already discloses this exact gap as a follow-up, so no action needed here — flagging only so it isn't lost.
Subagents
All N/A — this diff touches only package.json + package-lock.json, so parity-checker, i18n-syncer, contract-aligner, security-reviewer, and design-reviewer gates never trip.
Validation
Not independently re-run in this review session (npm ci and related commands were blocked by the review sandbox's own tool-approval layer). In its place I did a targeted field-by-field audit of the regenerated package-lock.json against every one of the 11 CVE targets and every one of the 7 hoisted Expo pins via grep, confirming each resolves to the claimed version at every nesting path. The PR body's self-reported local run (npm audit 0 vulnerabilities, turbo run lint type-check build test 11/11 green, suppressions ratchet unchanged at 734/733) was not independently reproduced but is consistent with the lockfile-level evidence.
One documentation note (non-blocking)
The PR body describes packages/shared/src/types/__generated__/api.generated.ts as "one unrelated file" needing a Zod re-baseline, but it is not in the actual diff — gh pr view --json files lists only package.json and package-lock.json, and git diff origin/main...HEAD -- packages/shared/src/types/__generated__/api.generated.ts is empty. That paragraph is stale from before main was merged into the branch; worth trimming from the description before merge, but not a defect in the diff.
What's good
- Every override is justified individually with the specific vulnerable chain it targets; the two line-scoped overrides (
brace-expansion@1,js-yaml@4) are correctly keyed to avoid dragging a healthy, unrelated major-version line backwards. - The Expo native-module float from regeneration was caught and pinned back to main's exact versions instead of silently accepted — a genuine root-cause fix, not a "good enough" lockfile regen.
orval/@orval/zodpinned to hold the generated Zod snapshot stable, correctly reasoned as necessary for the Contract Drift gate.
🤖 Generated with Claude Code
* fix: bump the three patchable vulnerable transitive deps Dependabot has five open high alerts, all npm transitives reached only through package-lock.json. Three have a published patch and are fixed here with the overrides block the repo already uses for exactly this (brace-expansion@1, and js-yaml@4 which this raises rather than adds). js-yaml@4 4.3.0 -> 4.3.1 GHSA-5p4m-2wfm-xmqj (eslintrc, xcpretty, orval) js-yaml@3 3.15.0 -> 3.15.1 GHSA-5p4m-2wfm-xmqj (@lhci/utils, dev) nanoid@3 3.3.16 -> 3.3.17 GHSA-2v37-7h3g-55p8 (expo-router, postcss) Every dependent's declared range already admits the patched version, so no dependent needed relaxing. npm reported the installed copies "invalid" against the new overrides but would not re-resolve them from the existing lock, so the lockfile was regenerated with `npm update js-yaml nanoid`. The remaining two alerts are image-size (GHSA-w3rx-r6r6-pgpr, GHSA-5p2g-fcmc-qvqq) and are NOT fixed, because no fixed release exists: the advisory range is <= 2.0.2 and 2.0.2 is the latest published version. npm's only proposed remedy is a major downgrade to expo 53 / react-native 0.72, which is a worse outcome than the bug. It is unreachable in production regardless: image-size is pulled by metro and runs in the bundler at build time, never shipped into the app. Validation: type-check 3/3, and 670 test files pass across all four workspaces. The full suite must be run with --concurrency=1; at turbo's default concurrency the shared barrel-import test at types.test.ts:1943 exceeds its 15s timeout purely from machine contention, unrelated to this change (shared imports neither package). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * chore(deps): sweep in-range dependency drift for August 2026 Monthly non-security freshness sweep. /dep-sweep and the reminder workflow that files these tickets were both deleted by #676, so this follows the contract stated in the ticket body instead: bump web and shared minor/patch, defer mobile to expo install --check, report the orbit-api NuGet drift without changing it. package-lock.json only. Every bump was already inside an existing semver range, so no package.json edit was needed. 263 packages moved, including next 16.2.11 -> 16.3.0, @sentry/* 10.68.0 -> 10.70.0, @supabase/supabase-js 2.110.8 -> 2.112.3, react-hook-form 7.82 -> 7.85, next-intl 4.13.4 -> 4.13.6, axios 1.18.1 -> 1.19.0, and 23 @radix-ui patch bumps. #599 recorded that regenerating this lockfile refloats transitives, so the pins that had to hold were checked against the base commit rather than by eye. Every exactly-pinned root override is identical: the Expo SDK 57 native module set did not move, orval and @orval/zod held at 8.20.0 so the committed Zod snapshot stays comparable, and react, react-dom and react-test-renderer held. The only override-pinned package that moved is postcss 8.5.23 -> 8.5.26, whose override is the caret range ^8.5.18, so that is the pin working as designed. Two things npm did that the invocation did not ask for. A hoisted lockfile ignores --workspace scoping, so Expo build tooling moved with the sweep (@expo/cli 57.0.10 -> 57.0.14, @react-native/* 0.86.0 -> 0.86.2); all in-range, all still SDK 57, none in the pinned native set. And brace-expansion moved 1.1.18 -> 1.1.16, a downgrade, because the lockfile had drifted above its own exact security pin and re-resolution pulled it back. Validation: lint 3/3 with 0 errors, type-check 3/3, and 670 test files pass across all four workspaces. The suite needs --concurrency=1; at turbo's default the shared barrel-import test at types.test.ts:1943 exceeds its 15s timeout from machine contention alone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
…nd de-flake the suite (#715) * fix: bump the three patchable vulnerable transitive deps Dependabot has five open high alerts, all npm transitives reached only through package-lock.json. Three have a published patch and are fixed here with the overrides block the repo already uses for exactly this (brace-expansion@1, and js-yaml@4 which this raises rather than adds). js-yaml@4 4.3.0 -> 4.3.1 GHSA-5p4m-2wfm-xmqj (eslintrc, xcpretty, orval) js-yaml@3 3.15.0 -> 3.15.1 GHSA-5p4m-2wfm-xmqj (@lhci/utils, dev) nanoid@3 3.3.16 -> 3.3.17 GHSA-2v37-7h3g-55p8 (expo-router, postcss) Every dependent's declared range already admits the patched version, so no dependent needed relaxing. npm reported the installed copies "invalid" against the new overrides but would not re-resolve them from the existing lock, so the lockfile was regenerated with `npm update js-yaml nanoid`. The remaining two alerts are image-size (GHSA-w3rx-r6r6-pgpr, GHSA-5p2g-fcmc-qvqq) and are NOT fixed, because no fixed release exists: the advisory range is <= 2.0.2 and 2.0.2 is the latest published version. npm's only proposed remedy is a major downgrade to expo 53 / react-native 0.72, which is a worse outcome than the bug. It is unreachable in production regardless: image-size is pulled by metro and runs in the bundler at build time, never shipped into the app. Validation: type-check 3/3, and 670 test files pass across all four workspaces. The full suite must be run with --concurrency=1; at turbo's default concurrency the shared barrel-import test at types.test.ts:1943 exceeds its 15s timeout purely from machine contention, unrelated to this change (shared imports neither package). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * chore(deps): sweep in-range dependency drift for August 2026 Monthly non-security freshness sweep. /dep-sweep and the reminder workflow that files these tickets were both deleted by #676, so this follows the contract stated in the ticket body instead: bump web and shared minor/patch, defer mobile to expo install --check, report the orbit-api NuGet drift without changing it. package-lock.json only. Every bump was already inside an existing semver range, so no package.json edit was needed. 263 packages moved, including next 16.2.11 -> 16.3.0, @sentry/* 10.68.0 -> 10.70.0, @supabase/supabase-js 2.110.8 -> 2.112.3, react-hook-form 7.82 -> 7.85, next-intl 4.13.4 -> 4.13.6, axios 1.18.1 -> 1.19.0, and 23 @radix-ui patch bumps. #599 recorded that regenerating this lockfile refloats transitives, so the pins that had to hold were checked against the base commit rather than by eye. Every exactly-pinned root override is identical: the Expo SDK 57 native module set did not move, orval and @orval/zod held at 8.20.0 so the committed Zod snapshot stays comparable, and react, react-dom and react-test-renderer held. The only override-pinned package that moved is postcss 8.5.23 -> 8.5.26, whose override is the caret range ^8.5.18, so that is the pin working as designed. Two things npm did that the invocation did not ask for. A hoisted lockfile ignores --workspace scoping, so Expo build tooling moved with the sweep (@expo/cli 57.0.10 -> 57.0.14, @react-native/* 0.86.0 -> 0.86.2); all in-range, all still SDK 57, none in the pinned native set. And brace-expansion moved 1.1.18 -> 1.1.16, a downgrade, because the lockfile had drifted above its own exact security pin and re-resolution pulled it back. Validation: lint 3/3 with 0 errors, type-check 3/3, and 670 test files pass across all four workspaces. The suite needs --concurrency=1; at turbo's default the shared barrel-import test at types.test.ts:1943 exceeds its 15s timeout from machine contention alone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: align mobile to Expo SDK 57 and repair the rotting override pins Closes the residual risk flagged on the August sweep, plus two override defects found while fixing it. expo install --check now reports "Dependencies are up to date". It previously wanted 26 packages moved, including react-native 0.86.0 -> 0.86.2 while six of its own tooling packages had already floated to 0.86.2, leaving core and tooling on different versions across the Android build. The 30 exact Expo pins in the root overrides block are deleted rather than refreshed. They existed to stop transitives refloating, but they are hand-maintained and silently rot, which is what produced the skew above. Removing them and measuring instead shows the tree dedupes on its own: duplicate expo/react-native module copies went from 1 to 0. The single remaining duplicate was react-native-device-info, hoisted 10.3.0 against react-native-siren's nested 8.7.1. Two copies of one native module cannot both autolink, so siren was running 8.x JS against 10.x native. It is now the one Expo-adjacent override that survives, because it is the only one carrying its weight. overrides: 45 entries -> 16 brace-expansion@1 was pinned to exactly 1.1.16, which is no longer a patched version. Two advisories now cover it, GHSA-mh99-v99m-4gvg (<1.1.17) and GHSA-rgw5-rvv9-x895 (<1.1.18, which bypasses the first mitigation). The tree had drifted to the safe 1.1.18 and the exact pin was dragging it back into both. Every security override is now a caret range so a pin cannot rot into the vulnerability it was added to fix. apps/mobile/package.json carried a 21-entry overrides block that npm never applied, since overrides are honoured only from the root workspace. #599 hoisted 7 of these; the block is now deleted outright. Not taken, each verified rather than assumed: eslint 10 eslint-config-next advertises eslint >=9.0.0, but its transitive eslint-plugin-react is at its last release (7.37.5), peers capped at ^9.7, and it throws "contextOrFilename.getFilename is not a function" on eslint 10. The brace-expansion override is the real fix regardless; eslint 10 was only npm's route to it. typescript 7 typescript-eslint@8.67.0 peers typescript <6.1.0. react 19.2.8 expo install --check rejects it and wants 19.2.3. Validation: lint 3/3 with 0 errors, type-check 3/3, 670 test files pass, and npm ci accepts the lockfile. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: stop the suite flaking when turbo runs four vitest instances at once `turbo run test` runs the four workspace suites concurrently and each vitest sizes its worker pool to the whole machine, so they oversubscribe the CPU. Tests that re-import a module graph then blow their timeout for no reason connected to the code under test. Reproduced before fixing: five consecutive default-concurrency runs, red every time, and the failure moved between workspaces rather than sitting on one test. shared types.test.ts barrel import, 15087ms against a 15s limit while its sibling barrels finish in 224ms to 490ms mobile use-push-notifications-state beforeEach, "Hook timed out in 10000ms", on a vi.resetModules() that rebuilds the graph per test web i18n/request and lib/server-fetch, the latter being the intermittent failure already filed as orbit-tickets #287 All four workspaces pass standalone, which is what identifies contention rather than a product defect as the cause. testTimeout and hookTimeout go to 30s in all three vitest configs. The inline per-test timeouts are deleted, because that is what made the first attempt at this fix fail: `it(..., 10000)` silently overrides the config, so raising the config alone left web red. Those magic numbers were an earlier pass at this same flake and each one resets the same clock as the suite grows. Verified with two further full default-concurrency runs, 4/4 tasks and 670 test files green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: cap vitest worker pools instead of leaning on long timeouts Addresses the Codex review on #715, which is right about the cause: 30s timeouts left four machine-sized worker pools oversubscribing the CPU and merely waited longer, while tripling how long a genuine hang takes to surface. maxWorkers is now '25%' in all three configs, so four concurrent workspace suites add up to about one machine's worth of workers instead of four. Confirmed against the installed vitest types rather than assumed: maxWorkers?: number | string, "Maximum number or percentage of workers". The cap alone is not sufficient, which is why the timeouts do not go all the way back to the defaults. Measured at default turbo concurrency: no fix 5 of 5 runs red 30s timeouts, no cap 2 of 2 green cap, default 5s timeouts 1 of 3 red, at 5000ms cap plus 15s margin 4 of 4 green 15s rather than the previous 30s, so a real hang reports in half the time while the residual cold-import cost still fits. One failure in the cap-only run was an AssertionError, not a timeout: server-fetch expecting forceRefresh: true on the second call. That is the pre-existing intermittent failure filed as orbit-tickets #287. It appears to be mock state cascading from the timed-out test above it in the same file, and it has not recurred in the four green runs, but this change does not claim to fix #287 because the cascade is unproven. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: cap the fourth vitest suite too Addresses the second Codex review on #715. The cap landed on mobile, web and shared but not eslint-rules, which kept vitest's default machine-sized pool and added workers on top of the three capped ones. That also made the comment wrong where it claimed four suites were capped. Its two test files make the practical pool small, but the config is what sets the ceiling, and on a 4-core CI runner the uncapped fourth is exactly where the aggregate goes back over one machine's worth. Verified with two more full default-concurrency runs, 4/4 tasks and 670 test files green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
Clears all 11 open Dependabot security alerts. Every alert is transitive through
package-lock.json, so this is a dependency-resolution change: npmoverridesin the rootpackage.json, each pinned to the first patched version or later. No application code changes.The 11 alerts
^8.5.18^0.35.0js-yaml@4brace-expansion@1^0.2.6^6.15.2^11.1.1Alerts 31, 30 and 1 are the same postcss chain and one override clears all three. Alerts 15 and 14 are the same tmp chain.
Why two overrides are line scoped
brace-expansionandjs-yamleach have a healthy major line in the tree alongside the vulnerable one, so a global override would drag the healthy line backwards and break its consumers:brace-expansion5.0.8, under sevenminimatch@5instances, is unaffected. Only theminimatch@3chain sat at 1.1.15, so the override is keyedbrace-expansion@1.js-yaml3.15.0, under@lhci/utils, is outside the advisory range and would break on a forced bump to 4.x, which droppedsafeLoad. Only orval's pinned 4.2.0 was vulnerable, so the override is keyedjs-yaml@4.The other five are single version lines in this tree, so a plain range override is enough.
Why the lockfile is regenerated
npm applies
overridesonly when it resolves an edge fresh. With an existing lockfile it treats the locked edges as authoritative and skips them. Verified againstnpm install,npm install --package-lock-only,npm install --forceandnpm update <pkg>: none of them moved the nestednext/node_modules/postcss@8.4.31ororval/node_modules/js-yaml@4.2.0. Evicting just the vulnerable nodes and reinstalling yields a tree with those packages missing entirely, so that is not viable either. A full regeneration is the only mechanism that applies them.Regeneration also refloats transitives inside the ranges
package.jsonalready declares. Three of those floats were not acceptable, so they are pinned back:Pins added to hold the regeneration steady
Expo native modules (7).
apps/mobile/package.jsoncarries its ownoverridesblock, but npm honoursoverridesonly from the ROOT workspace package.json, so those pins were never actually enforced. The regeneration therefore moved@expo/ui57.0.4 to 57.0.7, plus@expo/dom-webview,@expo/log-box,expo-eas-client,expo-json-utils,expo-manifestsandexpo-updates-interfaceoff 57.0.0. Those are native modules for the Android build. All seven are now hoisted into the rootoverridesat the exact versions main already had, so the native module set is byte-identical to main.orval (the contract-drift generator).
orvalfloated 8.20.0 to 8.22.0, which regenerates the committed Zod snapshot differently and would have made the Contract Drift gate unreadable.orvaland@orval/zodare pinned to 8.20.0 so the snapshot stays comparable.After those pins, the only remaining toolchain float is
eslint(10.6.0 to 10.8.0, 9.39.4 to 9.39.5). Lint and the Suppressions Ratchet both pass on it, counts unchanged at 734 and 733.Every other Expo and React Native package is unchanged:
expo,expo-router,expo-notifications,expo-modules-core,expo-updates,react,react-dom,next,typescript,react-native,react-native-screens,react-native-reanimatedandreact-native-worklets.One unrelated file: the Zod contract re-baseline
packages/shared/src/types/__generated__/api.generated.tsloses two lines. This is not caused by this PR. orbit-api commitafdc08de(landed today) removedclient_idfrom the OAuth token request body, so the committed snapshot went stale and the requiredContract Driftcheck now fails on every open PR in this repo, including one that changes nothing.Per
packages/shared/CONTRACT_DRIFT.mdthe generated file is never imported (it is a diff target only) and the fix is to re-baseline once you confirm the consumed part of the contract did not change. Nothing in this repo referencesclient_id,PostOauthTokenBodyor the OAuth token endpoint, so no hand-written schema insrc/types/*needed touching. It is included here only because Contract Drift is a required check and the security fix cannot merge without it.Verification
npm lsmarks the overridden packagesinvalid, which is what an override is by definition: a resolution that crosses the declaring package's range. No CI job runsnpm ls.Notes
sharpanduuidare both transitive:sharponly undernext(optional),uuidonly underxcode(runtime) and@lhci/cli(dev).xcodecallsrequire('uuid').v4(), which uuid 11's CJS build still exports, so the 7.x to 11.x jump is safe.uuid,sharporpostcss. The only app import among the eleven isdompurify, and 3.4.11 to 3.4.12 is a patch with an unchanged default export.mainis merged in here and the two changes agree, soapps/web/package.jsonno longer differs from main.apps/mobile/package.json'soverridesblock is dead weight, since npm ignores overrides outside the root workspace. The 7 pins this PR hoists are the ones that actually drifted; the rest of that block is still unenforced.🤖 Generated with Claude Code
https://claude.ai/code/session_018M2vH4pDvNnxUPecWWvwBc