chore(repo): add cargo ecosystem and group security updates in Dependabot config

[davidtaikocha]

Context

The repo had 39 open Dependabot PRs, the oldest from 2024-12-23. I closed 24 of them (stale, conflicting, superseded, or targeting packages that no longer exist); 15 mergeable ones remain. This PR fixes the config that let the backlog build up.

The key finding: only 2 of those 39 PRs came from dependabot.yml at all. Everything else was a Dependabot security update, which is a separate stream that ignores open-pull-requests-limit outright and ignores groups unless a group is explicitly marked applies-to: security-updates.

Proof that the two streams are distinct: cargo was not in dependabot.yml, yet #21713 and #22003 exist as cargo group PRs.

Changes

Change	Why
Add the cargo ecosystem (packages/taiko-client-rs, packages/ejector)	Both were getting zero version updates. taiko-client-rs has 129 commits in the last 6 months and runs in production. Two separate workspace roots, no root Cargo.toml, so both must be listed.
Add an applies-to: security-updates group to every ecosystem	The actual noise fix. Without it, a batch of alerts lands as one PR per package — ten were opened on 2026-05-14 alone (#21679–#21688).
Mark existing groups applies-to: version-updates	Previously implicit; making it explicit is what allows the paired security group to exist.
npm: keep directory: "/", add exclude-paths for the 5 dormant packages	nfts, snaefell-ui, taikoon-ui, ui-lib, supplementary-contracts have 0 commits in 6 months; version-bump PRs against them have no reviewer. See the note below on why exclude-paths rather than a directories: list.
npm: ignore version-update:semver-major	Majors rot when left to Dependabot. svelte 4→5, eslint 8→9, vite 5→6, vitest 1→3 all sat open for months and were closed unmerged.
open-pull-requests-limit 1 → 3	At 1, a single stuck group PR blocks its ecosystem for a whole cycle. Worth stating plainly: this setting never applied to security updates, so it was not what was holding PR count down.

Cadence stays monthly — the version-update stream was not the noisy one. go-updates and github-actions-updates have merged 20 times on that rhythm.

Why exclude-paths and not a directories: list

An earlier revision of this PR listed the six active workspace members under directories:. That was wrong twice over, and the correction is worth recording:

Dependabot's npm fetcher parses pnpm-workspace.yaml and glob-expands packages/* on its own, so directory: "/" already loads every member manifest:

fetch_files                              # npm_and_yarn/file_fetcher.rb:83
  -> pnpm_files                          # :136 (gated on pnpm_version, satisfied by the root pnpm-lock.yaml)
  -> fetch_pnpm_workspace_package_jsons  # :641
  -> workspace_paths(pnpm-workspace.yaml["packages"])   # glob-expands packages/*
  -> fetch_package_json_if_present(workspace)           # :725

So the six explicit entries were redundant, and the dormant packages were never excluded — the config's own comment claimed an exclusion it did not perform.

exclude-paths is the mechanism that actually works here, because it is checked inside fetch_package_json_if_present (:728) — the same helper the workspace expansion calls.

Two caveats, both now recorded inline in the config:

• exclude-paths is version-updates only (so marked in the options reference). It will not stop security PRs on the dormant packages; those still need dismissing in the Security tab, or the packages retiring.
• In dependabot-core the npm exclude-paths checks sit behind the experiment flag enable_exclude_paths_subdirectory_manifest_files. The option is publicly documented, so it is presumably enabled in production, but that is not verifiable from outside.

Open question for a maintainer — please read

The npm version-update lane has never produced a single PR. Exact-phrase search across all PR states:

"the npm-updates group" in:title  →  0
"the go-updates group"  in:title  →  20

This is not explained by directory scoping — as established above, directory: "/" was already reaching the whole workspace. And the root manifest alone has been updatable this entire time:

Dependency	package.json	pnpm-lock.yaml	Latest
prettier	^3.2.5	3.2.5	3.9.6 (in-range)
lefthook	^1.6.10	1.6.10	2.1.10 (major)

An in-range prettier bump should have been proposed long ago. It was not — which points at the npm updater job erroring out, and nothing in this PR would fix that.

Dependabot job logs are not exposed via the API, so I could not confirm it. Someone with admin access should check Insights → Dependency graph → Dependabot for the npm ecosystem's last run.

One lead worth checking there: pnpm-workspace.yaml uses onlyBuiltDependencies, a pnpm 10 key, while CI pins pnpm 9 (.github/actions/install-pnpm-dependencies/action.yml, taiko-client-rs--test.yml) and there is no packageManager field in the root package.json for Dependabot to read. I deliberately left package.json untouched here — pinning packageManager affects CI and belongs in its own PR.

Verification

• YAML parses; all 4 ecosystems carry both a version-update and a security-update group.
• Every declared directory has its manifest committed: go.mod, both Cargo.toml, root package.json.
• exclude-paths patterns checked against a faithful port of Dependabot::FileFiltering.exclude_path?: all 11 workspace members classify as intended (5 excluded, 6 kept) and the root manifest survives.
• Config-only change; no build or runtime impact.

Left as draft pending the Dependabot job-log check above.

🤖 Generated with Claude Code

[github-actions]

🐋 DeepSeek Code Review

🟡 Warnings

• exclude-paths for npm is not guaranteed to work in production. As noted in the PR itself, the npm exclude-paths filtering for subdirectory/workspace manifests is behind the Dependabot experiment flag enable_exclude_paths_subdirectory_manifest_files. If that flag is not enabled in GitHub’s production environment, the five “dormant” workspace packages will silently continue to receive version updates. This should be verified before treating the exclusion as effective; otherwise the config claims an exclusion it may not actually perform.

• The npm version-update stream may still be broken. The PR documents that npm version updates have never produced a PR, and points to a likely pnpm 9/10 mismatch:

  • pnpm-workspace.yaml uses onlyBuiltDependencies, a pnpm 10 key.
  • CI pins pnpm 9.
  • There is no root packageManager field.

  This config-only change does not fix that root cause. The new npm-updates group and ignore rules will not matter if the npm updater job continues to error out. The maintainer should confirm the Dependabot job logs before merge, or pair this with the pnpm/packageManager fix.

• exclude-paths does not apply to security updates. The dormant packages can still generate security PRs through npm-security. The security group reduces noise from one-per-package to one-per-ecosystem, but it does not exclude those packages. This is documented, but it means the “no reviewer” problem persists for security updates.

🔵 Suggestions

• Resolve the pnpm version ambiguity separately but promptly. Even if this PR is merged first, set packageManager in root package.json or align onlyBuiltDependencies with pnpm 9 so Dependabot has a consistent pnpm version to use.

• Consider adding reviewers/labels to the new cargo and security groups. Cargo packages are newly covered and security PRs can be broad; explicit routing avoids PRs sitting without a reviewer.

🟢 What Looks Good

• The two-stream model is accurately described: security updates ignore open-pull-requests-limit and require an explicit applies-to: security-updates group.
• Adding cargo for taiko-client-rs and ejector closes a real gap.
• Making existing groups explicitly applies-to: version-updates and adding paired security groups is correct.
• Raising open-pull-requests-limit from 1 to 3 is reasonable for grouped PRs.
• The config is syntactically valid and the comments are unusually useful.

---

Automatically triggered on PR update • model: deepseek-v4-pro