chore(deps): let dependabot cover the VS Code extension

[chethanuk]

Description

.github/dependabot.yml declares two ecosystems, gomod and github-actions, both at /. The
repo has 9 npm manifests: /package.json, six npm/*/package.json, pages/package.json, and
extensions/vscode/package.json.

The evidence that the gap matters is already in the tree.
extensions/vscode/package.json:110-116:

"resolutions": {
  "undici": ">=7.28.0",
  "form-data": ">=4.0.6",
  "js-yaml": "^4.2.0",
  "minimatch": "^9.0.7",
  "@typescript-eslint/typescript-estree/minimatch": "^9.0.7"
}

Someone is patching CVEs by hand, in a package dependabot never looks at. That's ongoing
manual work, not a hypothetical gap.

extensions/vscode/yarn.lock is tracked (226,661 bytes) and is # yarn lockfile v1 — Yarn
Classic, which dependabot's npm ecosystem supports. So there's a lockfile to work from and no
policy question.

Scope is deliberately narrow — one directory, not nine

Path	Included	Why
/extensions/vscode	yes	tracked yarn.lock, hand-pinned CVEs
/pages	no	its lockfile is gitignored (.gitignore:13) — that's your policy call, not mine
/ and the six npm/*/	no	zero real dependencies (only optionalDependencies on their own 0.0.0 stubs) — pure noise

  - package-ecosystem: npm
    directory: /extensions/vscode
    schedule:
      interval: weekly
    open-pull-requests-limit: 5
    ignore:
      # Bumping @types/vscode forces raising engines.vscode above ^1.74.0.
      - dependency-name: "@types/vscode"
    groups:
      vscode-dependencies:
        patterns:
          - "*"
        update-types:
          - minor
          - patch

Two parts of that are load-bearing rather than decoration:

• @types/vscode is ignored. package.json declares "engines": {"vscode": "^1.74.0"} and
  "@types/vscode": "^1.74.0" — they're a contract. Dependabot would happily bump the types to
  current, type-checking the extension against APIs that don't exist in the declared minimum VS
  Code. dart-frog-dev/dart_frog hit exactly this at the same path and fixed it with an ignore
  rule.
• update-types: [minor, patch]. The pending majors here are genuinely breaking: eslint ^8 → 9 (flat-config migration, and .eslintrc.json is present), @typescript-eslint ^6 → 8,
  @types/node ^18 → 24, @vscode/vsce ^3. A bare "*" group would bundle all of them into one
  unreviewable PR; this way majors arrive individually.

versioning-strategy is omitted on purpose — npm's default auto is right for an app with a
lockfile, and all three peers at this exact path (felangel/mason, dart-frog-dev/dart_frog,
arc53/DocsGPT) omit it too.

Peer shape: apache/airflow .github/dependabot.yml:48 uses a directories: list of 9 paths
under one ecosystem entry; 1Panel-dev/1Panel:1 pairs gomod with npm: /frontend, which is
almost exactly this repo's shape.

🚨 The thing you should weigh before merging

Nothing in CI builds or tests this extension.

$ grep -rn -E "yarn|vsce|extensions/vscode" .github/workflows/
(no matches)

No workflow runs yarn install, jest, webpack, eslint, or vsce package for
extensions/vscode — even though package.json defines all five scripts and there are 7 test
files under src/**/__tests__/. So every dependabot PR there would be checked only by
ci.yml, which is Go-only and entirely unaffected → green with zero validation. Merging on
green would be merging blind.

I'd rather flag that than have it discovered later. If you'd prefer an extension CI job first,
I'm happy to close this and revisit after.

Also worth naming, since the CVE pins are this PR's whole motivation: resolutions is not
maintained by dependabot — it's a yarn field, and the nested-path form
"@typescript-eslint/typescript-estree/minimatch" is a known source of npm-updater errors. This
PR reduces future manual pinning; it does not retire the existing block.

On the open dependabot queue

I noticed alibaba#340 (gomod) and alibaba#347 (actions) are both still open. Adding a third ecosystem to a
backlog that isn't being serviced is a fair objection, so: this entry is grouped and capped at
open-pull-requests-limit: 5, so it adds at most one PR per week, and the motivation isn't
routine churn — it's replacing the hand-written CVE pins above. If you'd rather not add an
ecosystem while the queue is backed up, I'm happy to close this and revisit.

Verification

$ python3 -c "...parse .github/dependabot.yml..."
version: 2
entries: [('gomod', '/'), ('github-actions', '/'), ('npm', '/extensions/vscode')]
limit: 5
ignore: [{'dependency-name': '@types/vscode'}]
groups: {'vscode-dependencies': {'patterns': ['*'], 'update-types': ['minor', 'patch']}}
versioning-strategy present: False

$ git diff origin/main -- .github/dependabot.yml | grep '^-' | grep -v '^---'
(no output — pure addition, both existing entries byte-identical)

Also confirmed first-hand: yarn.lock tracked and Yarn Classic v1; pages/package-lock.json
gitignored at .gitignore:13; engines.vscode and @types/vscode both ^1.74.0.

Limitations

• I have not seen dependabot actually run this config. GitHub validates dependabot.yml on
  push and surfaces parse errors in Insights → Dependency graph → Dependabot, but a schema-valid
  file is not proof that the first run behaves as intended.
• Expect a burst on the first run. Grouping plus open-pull-requests-limit: 5 contains it,
  but the initial batch will be larger than the steady state.
• I did not add an extension CI job, which is arguably the change that should come first — see
  above.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Refactoring (no functional changes)
• Documentation update
• CI / Build / Tooling

How Has This Been Tested?

• yaml.safe_load parses; asserted 3 entries, the new one's limit/ignore/groups shape, and
  that versioning-strategy is absent
• Confirmed the diff removes zero lines — both existing entries untouched
• Re-confirmed every premise first-hand: lockfile tracked + Yarn Classic, /pages lockfile
  gitignored, the engines/@types/vscode version contract, the five resolutions pins
• Confirmed no workflow references the extension

Checklist

• My code follows the project's coding style
• I have performed a self-review of my code
• I have added tests that prove my fix is effective — n/a, dependabot config
• New and existing unit tests pass locally with my changes
• I have updated the documentation accordingly (not applicable)
• I have signed the CLA

AI assistance: Claude Code helped research and verify this change. I reviewed the full diff
and take responsibility for it.

[coderabbitai]

Warning

Review limit reached

@chethanuk, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 9 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 3a4c6d93-f520-48f8-afc2-a704205ac9cb

📥 Commits

Reviewing files that changed from the base of the PR and between c60e886 and a846f61.

📒 Files selected for processing (1)

• .github/dependabot.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore/dependabot-vscode

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[gemini-code-assist]

Code Review

This pull request adds an npm package-ecosystem configuration to Dependabot for the '/extensions/vscode' directory. The review feedback suggests refining the ignore rule for '@types/vscode' to allow patch updates instead of ignoring the dependency entirely, ensuring compatibility with the engine constraints.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Instead of ignoring @types/vscode completely, you can restrict the ignore rule to only semver-major and semver-minor updates. This allows Dependabot to still supply patch updates (e.g., 1.74.x bug fixes) which remain fully compatible with the declared "engines": { "vscode": "^1.74.0" } constraint.

    ignore:
      # Bumping @types/vscode forces raising engines.vscode above ^1.74.0.
      - dependency-name: "@types/vscode"
        update-types:
          - "version-update:semver-major"
          - "version-update:semver-minor"

[chethanuk]

Good suggestion in principle, and it made me go check the actual state rather than the declared state — which turned up something worse. But the premise doesn't hold here.

The proposal assumes the installed version sits on 1.74.x, so that allowing patch updates would deliver 1.74.x bugfixes. It doesn't:

$ grep -A1 '^"@types/vscode' extensions/vscode/yarn.lock
"@types/vscode@^1.74.0":
  version "1.125.0"

^1.74.0 permits anything <2.0.0, so yarn already resolved to 1.125.0. The extension is type-checked against VS Code 1.125 APIs while declaring "engines": {"vscode": "^1.74.0"} — that mismatch is pre-existing in the tree, not something this entry introduces.

So with the ignore narrowed as suggested, the patch updates dependabot would actually offer are 1.125.0 → 1.125.1 — moving further from the engines floor, not 1.74.x bugfixes. Patch releases are rare here regardless: only 16 of 102 published minor lines ever shipped one.

Keeping the blanket ignore, but you were right that the comment was misleading — it framed the drift as hypothetical when it has already happened. Amended to say what's actually true:

    ignore:
      # yarn.lock already resolves @types/vscode far above the declared
      # engines.vscode floor (^1.74.0). Realign the two deliberately rather
      # than let a bot churn a version no CI job builds or type-checks.
      - dependency-name: "@types/vscode"

That last clause is the deciding factor: nothing in .github/workflows/ builds, lints or tests this extension (zero matches for yarn, vsce, extensions/vscode), so every dependabot PR at this path goes green with zero validation. Opening an extra unvalidated bump path for a types-only patch is negative value. Realigning engines.vscode and @types/vscode is a real behaviour change and belongs in its own PR, not a dependabot-config one.

[chethanuk]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.