Read the actual diff behind every dependency bump

The idea

A command-line tool that takes a lockfile diff and turns it into a readable code diff. Instead of lodash 4.17.20 → 4.17.21, you get the actual file-level changes between the two published tarballs, with the noise stripped out and the interesting parts pulled to the top: new install scripts, new network calls, new filesystem or child_process usage, new transitive dependencies. It runs locally as depdiff and in CI as a check on Dependabot and Renovate pull requests.

Why build this

Everyone merges dependency bumps without reading them. The information needed to review them exists — npm, PyPI, and crates.io all serve the published artifacts — but nobody assembles it, because doing it by hand means downloading two tarballs, unpacking them, and diffing thousands of lines of build output. Meanwhile the tag on GitHub often doesn't match what was actually published, which is exactly the gap the recent wave of registry compromises walked through.

The trend that makes this worth building now is automated bump PRs. A team running Renovate sees dozens of them a week and reviews none of them properly. A tool that reduces "should I merge this?" to a short annotated summary changes the default from rubber-stamp to skim.

Stack sketch

• Rust, distributed as a single static binary plus a GitHub Action wrapper — CI checks live and die on startup time.
• Registry clients for npm (registry.npmjs.org), PyPI (JSON API + wheels), and crates.io. Fetch the tarball, verify the integrity hash from the lockfile, never trust the git tag.
• similar for the diff engine; tree-sitter for JS/TS and Python to classify hunks by what they touch rather than by line count.
• Noise filters: skip minified bundles, sourcemaps, dist/ when a matching src/ exists, and pure whitespace or version-string churn. This filter is most of the product.
• A rules layer over the parsed tree: new postinstall/preinstall hooks, new fetch/http/net/requests imports, new eval/Function construction, newly added dependencies, sudden changes in maintainer or publish provenance.
• Local cache in ~/.cache/depdiff keyed by name@version, so the second run in CI is nearly free.

Scope for v1

In: - npm and PyPI only. - Reads package-lock.json, pnpm-lock.yaml, poetry.lock, and uv.lock — diff two revisions of the lockfile, or diff against HEAD. - Terminal output with a summary header, then a ranked list of changed packages, then per-package diffs behind a flag. - One GitHub Action that posts a single collapsible comment on bump PRs.

Out: - Any severity score or "safe/unsafe" verdict. Reporting facts is defensible; grading them is not. - CVE lookups. That's already covered by half a dozen tools, and mixing the two blurs what this is for. - A web dashboard.

Where it could go

The obvious next step is more ecosystems — Go modules and crates.io are close to free once the fetch-and-normalize layer is in place, and Maven is the one enterprises will pay for. Beyond that, the cache becomes a corpus: once you've diffed the same popular package for hundreds of users, you can precompute the diffs for the top few thousand packages and serve them from an API, so CI does a single lookup instead of two downloads.

The more interesting path is turning the rules layer into a policy file. Teams want to say "auto-merge anything whose diff touches no install hooks, adds no dependencies, and stays inside the existing import graph, and route everything else to a human." That's a merge queue gate, and it's what makes the tool something a company installs rather than something an individual runs twice.

Watch out for

Registry rate limits will bite in CI before anything else does — cache aggressively and support an authenticated token from the start. The subtler risk is the noise filter: one release that ships a build-system change will produce a 40,000-line diff, and if that happens on someone's first run they will never open the tool again.