If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/dependabot/dependabot-core shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 18 active contributors
• Distributed ownership (top contributor 32% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live dependabot/dependabot-core repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/dependabot/dependabot-core.

What it runs against: a local clone of dependabot/dependabot-core — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in dependabot/dependabot-core | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of dependabot/dependabot-core. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/dependabot/dependabot-core.git
#   cd dependabot-core
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of dependabot/dependabot-core and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "dependabot/dependabot-core(\\.git)?\\b" \\
  && ok "origin remote is dependabot/dependabot-core" \\
  || miss "origin remote is not dependabot/dependabot-core (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/dependabot/dependabot-core"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Dependabot-Core is the engine that generates automated dependency update pull requests for 12+ package managers (Ruby, JavaScript, Python, PHP, Go, Rust, Java, .NET, etc.). It detects available updates, resolves dependency conflicts, generates updated manifest/lockfiles, and creates rich PR descriptions with changelogs—the same logic powering GitHub's Dependabot service. Monorepo structured by ecosystem: lib/dependabot/{bundler,npm_and_yarn,pip,composer,go_modules,etc}/ contains language-specific logic; each has file_updater.rb, requirement.rb, and version.rb following a shared interface. Core abstraction lives in lib/dependabot/ (base classes), with integration points in lib/dependabot/clients/ (Git platform APIs). Helper executables for npm/yarn/pnpm live in helpers/ (TypeScript/JavaScript).

Developers and DevOps engineers maintaining open-source or internal projects who need automated dependency updates; platform teams building custom Dependabot instances for GitHub Enterprise, GitLab, Azure DevOps, or other Git hosts; maintainers of ecosystem-specific package managers wanting to add Dependabot support.

Highly mature and production-critical. The codebase is actively maintained with 12.9M lines of Ruby, extensive CI/CD pipelines (.github/workflows/ has 20+ workflows), comprehensive testing infrastructure, and Sorbet type checking enabled. This powers production Dependabot across GitHub.com and GitHub Enterprise.

Low risk for core logic, but moderate complexity: the repo manages 12+ language ecosystems with different versioning schemes and dependency resolution strategies, requiring deep knowledge of each ecosystem. Dependency risk is mitigated by pinned versions in package.json (npm 6.14.18, yarn-lib 1.22.22), but supporting multiple package managers means cross-platform brittleness is possible. Ecosystem-specific updaters (Ruby, npm, Python, etc.) live in separate directories and can have divergent quality.

Actively maintained with recent focus on: (1) Supporting additional package managers (Julia, Nix additions visible in file metrics), (2) Enhancing security features (codeql-analysis.yml, dependency-review.yml workflows), (3) Multi-language ecosystem support (C#, TypeScript, Go, Python), (4) Dev experience improvements (.devcontainer/on-create.sh, post-create.sh for rapid onboarding).

Clone and install: git clone https://github.com/dependabot/dependabot-core.git && cd dependabot-core && bundle install. Then use the devcontainer: code . and open in DevContainer for a fully configured Ruby + Node environment. Or manually: ruby --version (requires .ruby-version), bundle install, cd helpers && npm install.

Daily commands: Development: bundle exec rspec (run test suite), bundle exec rake (run default task, likely tests). For individual ecosystem testing: bundle exec rspec spec/dependabot/npm_and_yarn/ (example for npm). To run the full Dependabot logic: use the CLI entrypoint (not provided in file list—check README or lib/dependabot/cli for entry scripts). Helper scripts: cd helpers && npm test (for JavaScript helpers).

• lib/dependabot: Root of all package manager logic—each subdirectory (bundler, npm_and_yarn, pip, etc.) is a self-contained ecosystem updater with shared base classes
• lib/dependabot/file_updater.rb: Abstract base class that all ecosystem-specific updaters inherit from; defines the contract for generating updated manifest/lockfiles
• lib/dependabot/pull_request_creator.rb: Core logic for generating PR descriptions, handling commits, and pushing updates to Git platforms
• lib/dependabot/clients/: Adapters for GitHub, GitLab, Azure DevOps, BitBucket, AWS CodeCommit—abstracts Git platform differences
• helpers/: Node.js/TypeScript executables for npm, yarn, pnpm dependency resolution (called as subprocesses from Ruby)
• .github/instructions/: Developer guidelines covering class structure, code quality, testing, and updater implementation patterns
• .github/workflows/ci.yml: Main CI pipeline—defines how tests, Sorbet type checks, and linting run; reference for local test execution

Adding a new package manager: Create lib/dependabot/{ecosystem_name}/ with file_updater.rb, requirement.rb, version.rb, and test in spec/dependabot/{ecosystem_name}/. Fixing a version resolution bug: Look in lib/dependabot/{ecosystem_name}/file_updater.rb and the corresponding spec. Adding a Git platform: Extend lib/dependabot/clients/ (see github.rb, gitlab.rb patterns). Changing PR generation logic: Edit lib/dependabot/pull_request_creator.rb and test with spec/dependabot/pull_request_creator_spec.rb. Helper/npm issues: Check helpers/ directory (JavaScript/TypeScript code).

1. Helper subprocess communication: Ruby code calls Node.js helpers in helpers/ (npm, yarn, pnpm) via subprocess—requires both Ruby and Node.js environments and careful JSON serialization. 2. Ecosystem-specific version schemes: Each package manager has different versioning (SemVer vs. build metadata vs. pre-release notation)—copy-pasting version logic between ecosystems breaks silently. 3. Git API rate limits: All lib/dependabot/clients/ APIs hit real Git platforms; tests use VCR cassettes (fixtures) but live tests will hit rate limits if not cached. 4. Sorbet type checking is strict: Many files use # typed: strict, meaning you cannot add untyped code without explicitly opting out (see .rubocop.yml for type checking rules). 5. Monorepo gem releases: Changes to lib/dependabot/ affect all consuming gems (dependabot-bundler, dependabot-npm-and-yarn, etc.)—breaking changes ripple across gems.

• Dependency Resolution Graph — Core to Dependabot's logic—each ecosystem must build a dependency graph and check if a new version of a package is resolvable without breaking constraints from other dependencies; understanding semver resolution, version ranges, and conflict detection is essential
• Monorepo Multi-Package Distribution — Dependabot-Core is a monorepo publishing multiple gems (dependabot-bundler, dependabot-npm-and-yarn, etc.); changes to shared code in lib/dependabot/ affect all downstream consumers, requiring careful versioning and release coordination
• VCR Cassette-Based Testing — Tests record HTTP interactions with Git APIs (GitHub, GitLab, etc.) and replay them offline; critical for testing without hitting real rate limits and for reproducibility; stored in spec/fixtures/
• Manifest and Lockfile Updates — Dependabot must separately update semantic manifests (package.json, Gemfile, pyproject.toml) and generated lockfiles (package-lock.json, Gemfile.lock, poetry.lock); they have different mutation logic and version pinning rules
• Semantic Versioning and Version Schemes — Each ecosystem has different versioning rules (npm uses SemVer, Python uses PEP 440, Go uses pseudo-versions, etc.); Dependabot must parse and compare versions correctly per-ecosystem, found in lib/dependabot/{ecosystem}/version.rb
• Subprocess Communication for Language-Specific Resolution — Ruby code delegates npm/yarn/pnpm resolution to Node.js helper scripts (in helpers/) via subprocess calls with JSON serialization; understanding this boundary is critical for debugging resolution failures in JavaScript ecosystems

• renovatebot/renovate — Direct competitor solving the same problem (automated dependency updates) but Node.js-based; study Renovate's architecture for alternative approaches to multi-ecosystem dependency resolution
• actions/dependabot-action — GitHub Action wrapper around Dependabot-Core; reference for how to invoke and integrate this library in CI/CD workflows
• github/advisory-database — Companion repo providing security vulnerability data that Dependabot-Core consumes when generating update PRs with CVE information
• npm/npm — Upstream reference for npm ecosystem logic; understanding npm's dependency resolution is critical for the lib/dependabot/npm_and_yarn/ updater
• python-poetry/poetry — Companion tool for Python dependency management; Dependabot-Core's lib/dependabot/pip/ integrates concepts from Poetry's resolution algorithm

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive Jest tests for @dependabot/helper package with coverage reporting

The @dependabot/helper package has a test script defined but lacks visibility into test coverage. Given the critical nature of dependency resolution in npm, yarn, and pnpm (supported by dependencies like @npmcli/arborist, @dependabot/yarn-lib, and @pnpm/lockfile-file), adding Jest coverage thresholds and a coverage CI workflow would prevent regressions. The package currently lists nock as a dependency (for HTTP mocking) but likely needs more integration tests around lockfile parsing and resolution.

• [ ] Create jest.config.js with coverage thresholds (minimum 80% line coverage) in the @dependabot/helper directory
• [ ] Add integration tests in tests/ for npm, yarn, and pnpm lockfile parsing using nock for HTTP mocking
• [ ] Create .github/workflows/helper-coverage.yml to run Jest with coverage reports and fail on threshold drops
• [ ] Update package.json test script to include coverage flags: jest --coverage --maxWorkers=2

Add ESLint auto-fix and formatting CI checks with prettier integration

The @dependabot/helper has eslint and prettier as dev dependencies with a lint script, but there's no automated CI workflow enforcing code style. With eslint-config-prettier already configured, a CI workflow would catch formatting issues early. The package.json lacks prettier configuration, which is needed for consistent formatting across the helper module used by the core Ruby codebase.

• [ ] Create .github/workflows/helper-lint.yml to run eslint, prettier --check, and fail on violations
• [ ] Add .prettierrc.json in the helper directory with rules compatible with eslint-config-prettier
• [ ] Add npm script "format" in package.json: prettier --write . and "lint:fix": eslint . --fix
• [ ] Document linting requirements in CONTRIBUTING.md with specific instructions for the helper module

Add Node.js version matrix CI testing for @dependabot/helper across supported versions

The repository has .github/workflows/ci.yml for main testing, but there's no dedicated workflow testing the @dependabot/helper against multiple Node.js versions (14.x, 16.x, 18.x, 20.x). Given that this package is a critical bridge for npm/yarn/pnpm dependency resolution and is executed in Docker containers, verifying compatibility across versions prevents runtime failures. The .ruby-version file exists but Node version pinning is missing.

• [ ] Create .github/workflows/helper-node-matrix.yml testing against Node.js 16, 18, 20 LTS versions
• [ ] Add .nvmrc file with pinned Node.js version (e.g., 18.17.0) in the repository root
• [ ] Verify npm@6.14.18 (specified in package.json) works across all tested Node versions, flag incompatibilities
• [ ] Update CONTRIBUTING.md to document required Node.js version for local development of the helper

• Add missing test coverage for ecosystem-specific version bump logic: Navigate to spec/dependabot/{ecosystem}/requirement_spec.rb (e.g., pip, go_modules) and identify untested code paths in version requirement parsing. Add test cases for edge cases like pre-release versions, build metadata, or version ranges specific to that ecosystem.
• Improve error messages in ecosystem file updaters: Search lib/dependabot/{ecosystem}/file_updater.rb for generic raise statements and improve them with actionable context (e.g., 'Failed to update Gemfile for Ruby 2.7: dependency X not found' instead of 'Update failed'). Test in spec and run against real projects.
• Add Git client support for new platforms or extend existing adapters: Examine lib/dependabot/clients/ to identify gaps (e.g., missing error handling for 403 responses or unimplemented API methods for GitLab). Implement missing features by following patterns in github.rb or gitlab.rb and add tests using VCR cassettes in spec/dependabot/clients/.

The dependabot-core repository shows significant security concerns, primarily driven by severely outdated Node.js dependencies (npm 6.x and yarn-lib 1.x), both of which are no longer maintained and contain known critical vulnerabilities. The lack of visible lock files and use of permissive semver ranges compound these risks. Immediate action is required to update npm and evaluate yarn-lib alternatives. The project should implement stricter dependency management policies, regular audit processes, and CI/CD gates to prevent vulnerable versions from being deployed.

• High · Outdated npm Package with Known Vulnerabilities — package.json - dependencies.npm. npm version 6.14.18 is severely outdated (released in 2020). This version contains multiple known security vulnerabilities including CVE-2021-43565 (arbitrary code execution via git clone), CVE-2021-32804 (arbitrary file write), and many others. The current npm version is 10.x+. Fix: Update npm to the latest stable version (currently 10.x). Remove the pinned outdated version constraint and allow npm to be installed from a recent release.
• High · Vulnerable @dependabot/yarn-lib Version — package.json - dependencies.@dependabot/yarn-lib. yarn-lib version ^1.22.22 is outdated. Yarn 1.x reached EOL in January 2024. Multiple known vulnerabilities exist in older Yarn 1.x versions including insecure dependency resolution and potential code execution risks. Fix: Evaluate migration to Yarn 3.x or 4.x. If Yarn 1.x compatibility is required, update to the absolute latest 1.x patch version and conduct a security audit.
• Medium · Unaudited Transitive Dependencies — package.json / Dependency management. The package.json lacks a lock file in the provided context. Without a lock file (package-lock.json or yarn.lock), dependency resolution is non-deterministic. This can lead to inconsistent security postures across installations and CI/CD environments. Fix: Ensure package-lock.json is committed to the repository. Run 'npm ci' in CI/CD pipelines instead of 'npm install' to use exact locked versions. Regularly run 'npm audit' to check for vulnerabilities.
• Medium · Patch-Package Postinstall Script Risk — package.json - scripts.postinstall. The postinstall script runs 'patch-package' which modifies node_modules after installation. While patch-package is legitimate, postinstall scripts can be a vector for supply chain attacks if dependencies are compromised. This increases the attack surface. Fix: Verify the necessity of patch-package. Consider using package overrides or workspace dependency resolutions instead. If patch-package is necessary, ensure all patches are reviewed and committed to version control.
• Medium · Overly Permissive Semver Ranges — package.json - multiple dependencies. Multiple dependencies use caret (^) version constraints allowing minor and patch updates without review. For critical dependencies like npm, @dependabot/yarn-lib, and @npmcli/arborist, this can introduce breaking changes or vulnerabilities without explicit approval. Fix: Use tighter version constraints (e.g., ~1.22.22 or exact versions) for security-critical dependencies. Implement automated dependency update workflows with testing gates.
• Low · Missing npm Audit Configuration — package.json / Repository root. No npm audit configuration visible in package.json. Without audit configuration (.npmrc or package.json auditConfig), the baseline for security checks may not be enforced in CI/CD pipelines. Fix: Add auditConfig to package.json or .npmrc to fail builds on medium+ severity vulnerabilities. Example: add 'audit-level': 'moderate' in auditConfig.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.