chore(deps): stop Dependabot bumping Expo SDK-governed packages

[toruiwasa]

Closes #124

Split out of #118. Configuration only — no application code, no lockfile change.

Why now

PR #123 arrived carrying exactly the payload #118 predicted:

-    "react-native": "0.86.2",          ← Expo SDK 57 expects 0.86.x
+    "react-native": "0.87.1",
-    "react-native-reanimated": "4.5.1",
-    "react-native-worklets": "0.10.1",
+    "react-native-reanimated": "4.6.0",
+    "react-native-worklets": "0.12.1",   ← the 0.12 API break from #117

expo/bundledNativeModules.json fixes the version of 14 of apps/mobile's dependencies for the SDK in use. Dependabot has no knowledge of that matrix, so it proposes whatever npm published last.

For the two packages also pinned by overrides in pnpm-workspace.yaml, the failure is quieter: pnpm rewrites the specifier back to the override, pnpm install --frozen-lockfile still passes, and the PR goes green while package.json declares a version that is neither installed nor linked. Verified with a minimal repro on pnpm 11.5.2.

The list is derived, not curated

14 entries = bundledNativeModules.json ∩ apps/mobile dependencies. The regeneration command is in the comment, so the next reader can re-derive it rather than trust it:

@react-native-community/netinfo  eslint-config-expo  expo-constants  expo-linking
expo-router  expo-secure-store  expo-status-bar  jest-expo  react  react-native
react-native-reanimated  react-native-safe-area-context  react-native-screens
react-native-worklets

expo itself is deliberately not listed. Its version is not in its own map, and its bump is the signal that the other 14 may move. It must keep arriving.

Not listed either: react-native-mmkv and react-native-nitro-modules. They are native modules but not Expo-governed, so Expo has no opinion on their versions and Dependabot should keep proposing them. Whether those can break the native build is #118's question, not this one.

Security updates still arrive — this is why update-types is spelled out

Each rule lists all three version-update:semver-* types instead of being a bare dependency-name rule. Naming the version-update types scopes the rule to version updates, so Dependabot security updates for these packages are unaffected. A bare rule would suppress those too — which is what an earlier draft of this guard would have done.

Verification

• .github/dependabot.yml parses; the resulting ignore list is the 14 derived names each with major/minor/patch, plus the pre-existing typescript (major only) rule intact
• Groups (angular, nestjs, dev-tooling, production-deps) and both ecosystems (npm, github-actions) unchanged
• No other file touched

Sequencing note

#118 originally argued this guard should ship only alongside its expo install --check gate, so the pin could not silently age. That is reversed here on purpose: #123 shows the harmful PR arrives weekly, while the pin was set to match SDK 57 days ago and needs no near-term lift. #118 still owns the check, which is what will later detect a stale pin — measured, it reads installed versions, so it catches an aged pin but never a Dependabot bump. The two are complementary.

This must reach main before the next scheduled run: Dependabot reads its config from the default branch only.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
pulseticker	Ready	Preview	Sep 5, 2026 2:36am UTC