feat: add a transitive dependency audit to the dashboard - #26

What & why

Renovate's per-fork dependency dashboards can only flag what appears in a package.json. An abandoned package reachable only transitively is therefore invisible to every dashboard in the org. Run against the 27 published forks today, that blind spot hides 34 of the 63 abandoned-with-dependencies packages sitting in their trees.

scripts/dep_audit.py closes it. It resolves each fork's full production tree and classifies every node, rendering a panel on the main dashboard plus a standalone dependencies.html next to topology.html.

How the tree is resolved

npm install --package-lock-only --omit=dev --ignore-scripts in a scratch directory, then the resolved graph is read out of the lockfile. npm walks registry metadata only — no tarball is downloaded and no package lifecycle script ever executes, which matters given this workflow runs in the org's CI. The whole org resolves in about 25 seconds.

Reading each node's own dependency count from the lockfile rather than from a per-version registry request is deliberate. The per-version endpoint 404s on versions that exist ([email protected] is one), and a caught 404 silently looks like "zero dependencies", which misclassifies a time bomb as inert. The lockfile is npm's own resolution and can't disagree with itself.

The classification

It turns on whether an abandoned package can still rot, which is the distinction that decides what to do about it:

Being "on latest" is not a health signal when latest is itself frozen, so the audit reports last-release dates rather than version drift.

Where one name resolves to different versions across forks and those versions classify differently, the worst state wins. That keeps the rollup honest about real exposure and makes the totals independent of the order forks are audited in — verified by re-running with the fork list reversed.

The cross-check that earns its own section

A fork's tree may contain the abandoned upstream copy of a package this org already maintains, because the fork was never repointed at its sibling. That is 22 packages across 11 forks today — self-inflicted rot, and mechanical to fix. It is derived by intersecting each tree against the set of packages the org publishes, so it needs no maintenance as forks are added.

Current output

143 unique packages across the trees — 63 time bombs (34 invisible), 46 inert, 34 alive. The three classes partition the total exactly.

Design rules honoured

• Derived, never recorded. Everything is computed at build time; nothing is written to a file and no central registry is introduced. Adding a fork requires no edit here.
• Best-effort. A fork that fails to resolve degrades to a single "unresolved" row rather than failing the build (@unabandoned/browserify-sign is unpublished today and exercises this path). The entire section is omitted if npm is unavailable.
• No new dependencies. Python stdlib plus the npm already present on the runner. The dev tree is untouched.

Verification

• dep_audit.audit() run against all 27 published forks plus one unpublished package: 25.8s, correct degrade row, totals partition exactly, order-independent.
• Rendered dependencies.html inspected — 3 tables balanced, 21 <div> open/close balanced, no unsubstituted placeholders, unresolved row present.
• py_compile clean on all three scripts; render() signature and its call site updated together.
• The builder's GitHub-discovery half could not be exercised here — api.github.com is blocked by this session's egress policy — so main will be the first end-to-end run. The audit is additive and independently tested, and the workflow's paths: trigger now includes the new script so a rebuild fires on merge.

Type of change

• fix / feat / perf — consumer-facing
• deps — dependency update (add the security label if it fixes a CVE)
• chore / ci / build / docs / test / refactor — maintenance

Checklist

• Commits follow Conventional Commits (commitlint passes)
• npm test passes on Node 20 / 22 / 24 — n/a, this repo ships no npm package; the changed code is Python and the workflow that runs it
• No new runtime dependency (or its addition is justified below) — none; stdlib only
• Dev tree kept lean (prefer built-in node:test over new runners) — unchanged

Generated by Claude Code