ci(renovate): cover the whole @expo/ scope; drop the phantom @expo/fingerprint dep #17

Merged

ullrich merged 2 commits from ci/expo-scope-and-fingerprint into main 2026-07-26 17:59:35 +00:00

Conversation 0 Commits 2 Files changed 3 +8 -27

ullrich commented 2026-07-26 17:58:44 +00:00

Owner

Copy link

Two commits. The first re-lands work that was orphaned by PR #16, the second acts on what that work uncovered.

1. Re-land: @expo/ scope rule (was orphaned)

I pushed this to ci/renovate-expo-sdk after PR #16 had already merged, so it never reached main — main still carried the narrow "@expo/metro-runtime" rule. My mistake: I treated an open PR as still mine to amend, which is exactly the hazard CLAUDE.md warns about.

The rule now matches /^@expo\// rather than naming packages individually. The authoritative source is expo/bundledNativeModules.json in the installed SDK — 121 pinned packages for SDK 56, four under the @expo/ scope:

Package	SDK 56 pins	Repo declared
@expo/fingerprint	~0.19.4	^0.20.3 ← off-pin
@expo/metro-runtime	~56.0.15	^56.0.15 ✓
@expo/ui	~56.0.18	not used
@expo/vector-icons	^15.0.2	not used

Matching the scope means a newly-added @expo/* is covered by default instead of drifting until someone notices — which is what had already happened.

2. Drop @expo/fingerprint (option 2, tested)

It was added by 3da7b8d ("Fix lockfile sync") and nothing imports it — a phantom direct dependency. Because it was never intentional, its version was never aligned to the SDK.

Removing it does not merely stop the drift, it corrects it: expo already brings the package transitively through @expo/cli, and that resolution is 0.19.4 — exactly the SDK pin.

@expo/fingerprint@0.19.4
└─┬ expo@56.0.12
  ├─┬ @expo/cli@56.1.16

Verified rather than assumed:

• pnpm install --frozen-lockfile (what CI runs) → exit 0
• still present as a transitive dep (3 lockfile refs)
• pnpm typecheck → 14/14 tasks pass

Pre-existing issue noticed, NOT introduced here

@expo/log-box@56.0.13 requires @expo/dom-webview@^56.0.5, but the tree resolves 55.0.5. I checked: identical on main, so this predates the PR — pnpm only reports peer problems when it recalculates resolution, which is why it shows up in this PR's install output.

It is another instance of exactly the SDK-family drift these rules exist to prevent, and worth its own look — an SDK bump with expo install --fix would likely resolve it.

Two commits. The first **re-lands work that was orphaned** by PR #16, the second acts on what that work uncovered. ## 1. Re-land: `@expo/` scope rule (was orphaned) I pushed this to `ci/renovate-expo-sdk` after PR #16 had already merged, so it never reached `main` — `main` still carried the narrow `"@expo/metro-runtime"` rule. My mistake: I treated an open PR as still mine to amend, which is exactly the hazard CLAUDE.md warns about. The rule now matches `/^@expo\//` rather than naming packages individually. The authoritative source is `expo/bundledNativeModules.json` in the installed SDK — **121 pinned packages** for SDK 56, four under the `@expo/` scope: | Package | SDK 56 pins | Repo declared | |---|---|---| | `@expo/fingerprint` | `~0.19.4` | **`^0.20.3`** ← off-pin | | `@expo/metro-runtime` | `~56.0.15` | `^56.0.15` ✓ | | `@expo/ui` | `~56.0.18` | not used | | `@expo/vector-icons` | `^15.0.2` | not used | Matching the scope means a newly-added `@expo/*` is covered by default instead of drifting until someone notices — which is what had already happened. ## 2. Drop `@expo/fingerprint` (option 2, tested) It was added by `3da7b8d` (*"Fix lockfile sync"*) and **nothing imports it** — a phantom direct dependency. Because it was never intentional, its version was never aligned to the SDK. Removing it does not merely stop the drift, it **corrects** it: `expo` already brings the package transitively through `@expo/cli`, and that resolution is **`0.19.4`** — exactly the SDK pin. ``` @expo/fingerprint@0.19.4 └─┬ expo@56.0.12 ├─┬ @expo/cli@56.1.16 ``` Verified rather than assumed: - `pnpm install --frozen-lockfile` (what CI runs) → exit 0 - still present as a transitive dep (3 lockfile refs) - `pnpm typecheck` → 14/14 tasks pass ## Pre-existing issue noticed, NOT introduced here `@expo/log-box@56.0.13` requires `@expo/dom-webview@^56.0.5`, but the tree resolves **55.0.5**. I checked: identical on `main`, so this predates the PR — pnpm only reports peer problems when it recalculates resolution, which is why it shows up in this PR's install output. It is another instance of exactly the SDK-family drift these rules exist to prevent, and worth its own look — an SDK bump with `expo install --fix` would likely resolve it.

ullrich added 2 commits 2026-07-26 17:58:47 +00:00

ci(renovate): cover the whole @expo/ scope, not just metro-runtime ... 3f3a4c29af

Naming @expo/metro-runtime individually missed the rest of the scope. The
authoritative list is expo/bundledNativeModules.json in the installed SDK: 121
pinned packages for SDK 56, four of them under @expo/ — fingerprint,
metro-runtime, ui and vector-icons. Matching the scope means a newly-added
@expo/* package is covered by default rather than drifting until someone
notices, which is precisely what happened below.

Found while checking: @expo/fingerprint is SDK-pinned at ~0.19.4 but the repo
declares ^0.20.3, so it is ALREADY ahead of its pin — and Renovate had it queued
in the "development" group, which would have pushed it further. It arrived via
3da7b8d ("Fix lockfile sync: add @expo/fingerprint to root devDependencies") and
nothing in the codebase imports it, so its version was never aligned to the SDK.
Left as-is here rather than downgraded silently; noted on the PR for a decision.

chore(deps): drop the phantom @expo/fingerprint direct dependency ... d7788de8aa

It was added by 3da7b8d ("Fix lockfile sync: add @expo/fingerprint to root
devDependencies") and nothing in the codebase imports it — it existed only to
satisfy lockfile resolution. Because it was never an intentional dependency, its
version was never aligned to the SDK: it sat at ^0.20.3 while SDK 56 pins
~0.19.4, and Renovate had it queued in the development group to push it further
off-pin.

Removing it does not just stop the drift, it corrects it. `expo` already brings
the package transitively via @expo/cli, and the transitive resolution is
0.19.4 — exactly the SDK pin.

Verified: `pnpm install --frozen-lockfile` (what CI runs) exits 0, the package
is still present as a transitive dep, and `pnpm typecheck` passes across all 14
tasks.

Unrelated pre-existing drift noticed while testing, NOT introduced here:
@expo/log-box@56.0.13 wants @expo/dom-webview@^56.0.5 but the tree resolves
55.0.5 — identical on main. pnpm only surfaces it when it recalculates
resolution, which is why it appears in this PR's install output.

ullrich merged commit 0cb3d7c17a into main 2026-07-26 17:59:35 +00:00

ullrich deleted branch ci/expo-scope-and-fingerprint 2026-07-26 17:59:36 +00:00

ullrich referenced this pull request from a commit 2026-07-26 17:59:37 +00:00

Merge pull request 'ci(renovate): cover the whole @expo/ scope; drop the phantom @expo/fingerprint dep' (#17) from ci/expo-scope-and-fingerprint into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

dependencies

Dependency updates raised by Renovate (renovate.json5 labels)

  

major

Major version bump — always needs human review, never auto-merged

  

security-pin

Touches a pnpm.overrides CVE remediation pin, not an ordinary dependency

No labels

dependencies

major

security-pin

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

trails-cool/trails!17

No description provided.