fix(diff): detect upgrades for versioned purls (headline feature was broken for real SBOMs)

[dmchaledev]

Summary

Upgrade detection — a headline feature of this tool ("Highlights added, removed, upgraded dependencies") — is broken for essentially every real-world SBOM. A simple patch bump is reported as a removal plus an addition, and the upgraded list stays empty.

Root cause

buildComponentMap in src/diff.ts keyed each component by its full purl:

const key = comp.purl ?? comp.name;

But a purl embeds the version (pkg:npm/lodash@4.17.21). Real SBOM generators (syft, cdxgen, Trivy, …) always emit versioned purls, so lodash@4.17.20 and lodash@4.17.21 get different keys — the old one looks removed, the new one looks added, and no upgrade is ever detected. Upgrades were only found in the rare case where components had no purl and matched by name (see the existing name-fallback test).

Reproduction (before)

$ sbom-diff old.json new.json   # lodash 4.17.20 -> 4.17.21, both with purls
Summary:
  Added:       1
  Removed:     1
  Upgraded:    0      # ← should be 1

Fix

Derive component identity from the version-independent purl coordinates — strip the @version suffix (plus any ?qualifiers / #subpath), falling back to the component name when no purl is present. Per the purl spec any literal @ in a name is percent-encoded, so scoped npm packages like pkg:npm/%40angular/core@16.0.0 stay correct.

After the fix the same input reports Upgraded: 1 with 4.17.20 → 4.17.21, and add/remove/major-bump detection is unchanged.

Changes

• src/diff.ts — new componentKey / purlWithoutVersion helpers; buildComponentMap keys on version-independent identity.
• src/__tests__/diff.test.ts — replaced the test that documented the old broken behavior with tests asserting upgrade detection for versioned purls, purls with qualifiers, and scoped npm purls (major bump).
• CHANGELOG.md — Fixed entry under [Unreleased].

Testing

• npm test — 40 passing (was 38)
• npm run lint — clean
• npm run build — clean

Notes / scope

Kept intentionally focused. When a single SBOM legitimately lists two versions of the same package, version-independent keys make them collapse (last-write-wins) — that is the separate concern already tracked in #50 and is out of scope here.

---

Generated by Claude Code