fix: correct three dashboard miscounts — aliases, topology edges, and the Renovate dashboard issue - #28

What & why

Three places where the dashboard reported numbers that were wrong. Two share a root cause; the third is independent.

1 & 2 — npm alias syntax read as the upstream package

The forks wire themselves to their siblings with npm's alias syntax:

"buffer": "npm:@unabandoned/buffer@^6"

That keeps require('buffer') working unchanged while pulling our fork. The scope lives in the spec, not the key — and both readers added in #26 looked only at keys.

dep_audit.py — forks counted as their own abandoned upstreams

A lockfile key is only where a package was placed; name is what it is. Reading node_modules/buffer as buffer dated our freshly published fork from upstream buffer's 2020 packument and filed it as an abandoned time bomb.

Worse, it invented an entire class of finding. Every aliased entry looked like a fork pulling its abandoned upstream, so the audit reported 22 such packages across 11 forks. The real number is 4, and no fork declares any of them — they arrive through third-party intermediates (browserify-sign and hash-base depend on readable-stream@^2.3.8, through2 on ^4.7.0), so no fork's package.json can repoint them. The self_hosted section was reporting the org's correct wiring as self-inflicted rot.

build_dashboard.py — the topology graph was never empty

The same blind spot made every fork → fork edge invisible: a dependency keyed buffer never matched the package id @unabandoned/buffer. That is why the graph rendered as isolated nodes with only used-by edges. The data was there the whole time. resolve_dep_name() now resolves an npm: spec to its target.

This one predates #26 — it is the original cause of the sparse topology panel.

Corrected numbers

alive rises by 23 because our own forks stop being counted as the packages they replaced. The three classes still partition the total exactly (46 + 44 + 57 = 147).

3 — the Renovate Dependency Dashboard counted as an open issue

It is a control surface, not work: always open, present on every fork, and already surfaced on the card as its own "updates" link. Counting it as an issue double-counted it and put a permanent floor of 1 under every fork, so no fork could ever show a clean zero.

Across the 27 forks the dashboard reported 29 open issues where only 2 are real work. The org-wide total was almost entirely noise.

Now matched on the bot author as well as the title, so a human-filed issue that happens to share the name still counts as real work.

Verification

• dep_audit.audit() re-run against all 27 published forks: partition exact, self_hosted down to the 4 genuine cases, @unabandoned/browserify correctly showing 17 sibling dependencies resolved through aliases.
• resolve_dep_name() checked against npm:@unabandoned/buffer@^6, npm:@unabandoned/jsonstream@^1, npm:@unabandoned/ret@^0.5, npm:plain-pkg@^1 and ^8.18.0.
• Cross-checked the other direction: every published fork's manifest has zero non-aliased dependencies on a package the org owns — the correct state, and it matches what the aliases say.
• Issue-count filter table-tested across five cases: bot dashboard excluded, link still surfaced, a same-titled human issue still counted, PRs in the issues feed still excluded, and forks with no dashboard unaffected.
• py_compile clean.

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
• No new runtime dependency (or its addition is justified below) — none
• Dev tree kept lean (prefer built-in node:test over new runners) — unchanged