Discover dependency versions

Dependency Graph & Version Discovery

When to Use

Use before planning, diagnosing, or executing any package upgrade, security remediation, lockfile resolution, or runtime update. Never edit a manifest or run a package manager command until you have mapped what is declared, what is locked, and what is actually resolved at build and runtime.

Three-Layer Version Truth

Every dependency exists in three distinct states that frequently diverge:

1. Declared Range (Manifest): What package.json, composer.json, pyproject.toml, or Cargo.toml requests (^4.18.0, ~2.1, >=1.8,<2.0).
2. Locked Resolution (Lockfile): What package-lock.json, pnpm-lock.yaml, yarn.lock, composer.lock, uv.lock, poetry.lock, or Cargo.lock pins via exact version, registry URL, and integrity hash (sha512-..., sha256-...).
3. Installed / Materialized Artifact: What sits in node_modules/, vendor/, .venv/, or Cargo cache, and which copy the module loader or bundler actually resolves when duplicates exist.

Ecosystem Discovery Checklist

1. Identify Package Manager & Exact Tooling Version

• Inspect packageManager in root package.json (Corepack pin), .nvmrc, .node-version, .tool-versions, mise.toml, rust-toolchain.toml, .python-version, composer.json config.platform, and CI / Dockerfile runtime images.
• Match the active lockfile (package-lock.json $\rightarrow$ npm, pnpm-lock.yaml $\rightarrow$ pnpm, yarn.lock + .yarnrc.yml $\rightarrow$ yarn, bun.lock/bun.lockb $\rightarrow$ bun, composer.lock $\rightarrow$ composer, uv.lock/poetry.lock/requirements*.txt $\rightarrow$ uv/poetry/pip-tools, Cargo.lock $\rightarrow$ cargo). Never mix package managers or create a second lockfile.

2. Map Direct vs. Transitive Dependencies & Roles

• Production (dependencies, require, [project.dependencies]): Executed in production; breaking changes or CVEs directly affect live behavior.
• Development / Build (devDependencies, require-dev, [dependency-groups], [dev-dependencies]): Compilers, bundlers, test runners, linters, codegens. Affect production when they emit bundles, types, or schema code.
• Peer Dependencies (peerDependencies, peerDependenciesMeta): Host-provided contracts (react, vue, @angular/core, typescript, postcss, eslint). Tightened peer ranges require verifying host compatibility.
• Optional & Platform-Specific (optionalDependencies, os, cpu, libc, Cargo cfg(...), Python markers): Native binaries (@rollup/rollup-*, @swc/core-*, sharp, esbuild, fsevents).

3. Trace Dependency Chains & Duplicate Resolutions

Use native read-only graph queries:

• Node: npm explain <pkg>, npm ls <pkg> --all, pnpm why <pkg> -r, yarn why <pkg>
• PHP: composer why <vendor/pkg> and composer why-not <vendor/pkg> <target-version>
• Python: uv tree --package <pkg>, poetry show --tree
• Rust: cargo tree -i <crate> and cargo tree -d (duplicate crate versions)

4. Audit Overrides, Patches & Baseline Health

• Inspect overrides (npm/pnpm), resolutions (yarn), pnpm.patchedDependencies, patch-package, composer-patches, [tool.uv.override-dependencies], and Cargo [patch.crates-io] to see if the target version upstreamed the fix.
• Run baseline typecheck, build, and targeted tests before touching versions to separate pre-existing failures from upgrade regressions. Upgrade coupled package families (@babel/*, @tanstack/*, symfony/*, @opentelemetry/*) together, and watch for dual-package hazards (ESM + CJS or two majors of graphql, rxjs, zod, @prisma/client).