Paste two lockfiles → a semver‑classified upgrade summary.
package.json for verified directness
applied to both lockfiles
Without it, the Direct column is inferred from lockfile structure (npm v2/v3 and pnpm can be trusted; npm v1 and yarn cannot attribute directness at all).
What it does. lockfile-diff answers the review question a 4,000-line
lockfile diff buries: what actually changed, and how risky is it? It parses both
pastes into a normalized package model — npm package-lock.json v1/v2/v3,
pnpm-lock.yaml, and yarn.lock classic and Berry, auto-detected
— then classifies every version change by semver distance: major (breaking-change
territory), minor, patch, plus packages added and removed. The
result copies out as a Markdown table for the PR description. Everything runs on a pure,
dependency-free core in this tab; the lockfiles never leave your device.
The directness caveat (read before trusting the Direct column). The
Direct badge is inferred from lockfile structure alone — this tool does
not read your package.json unless you paste one into the optional box
above. That matters because the formats differ in what they record: package-lock
v2/v3 and pnpm lockfiles encode the project’s declared dependencies, so
their direct/transitive booleans can be trusted; package-lock v1 and
yarn.lock (classic and Berry) do not record which resolved entries the
project itself declared — that information lives only in package.json
— so rather than guess, every such entry honestly reports directness as
unknown. Pasting a package.json upgrades all of them to verified
booleans.
Other honest limits. The pnpm/Berry parser understands the subset of YAML
those tools actually emit, not arbitrary YAML. And a semver classification is a
distance, not a safety proof: a patch bump can still break you (the
colors 1.4.1 sabotage of January 2022 hung apps from a patch release), and
pre-1.0 packages legitimately break on minor bumps — the summary tells you
where to look first, not what to skip reading.