I built node-modules-map to answer a practical question: which installed packages own the file bytes under node_modules, and what changed between two installs? It's a dependency free Node CLI that writes a portable HTML report or JSON snapshot.
The report is a treemap. It can show installed copies or group them by package name. I can filter by name, path, or version, zoom into a name group, and select a copy to see its installed path, version, byte count, copy count, and largest files. Empty packages stay in the package index. The compare command validates two snapshots and reports byte and copy changes by package name and version, including paths that appeared or disappeared.
The browser demo uses a real npm install with Vite, TypeScript, esbuild, lodash, and a second lodash version installed through an npm alias. The exact versions and measured scan totals are in the repository.
I kept the report self contained. It needs no server, external assets, CDN, or analytics. The scanner reads manifests and filesystem metadata. It accepts npm node_modules trees, rejects pnpm virtual stores, skips other symbolic links with warnings, and fails on unreadable directories.
The accounting is narrow: it sums regular file stat.size values and counts hard linked paths independently. It doesn't report allocated blocks or claim duplicate bytes are reclaimable. A comparison records observed snapshots, so it can't guarantee an atomic view while files are changing.
There are established tools for interactive dependency inspection, including node-modules-inspector, which also supports pnpm and bun. I focused this project on portable HTML reports and validated comparisons for npm trees.
The source, commands, and demo record are available at https://github.com/Arthur031221/node-modules-map. The README has the local quickstart and limitations. I'd be interested in feedback on which comparison details are most useful when reviewing dependency changes.
Top comments (1)
For dependency reviews, I'd put path churn beside the byte delta: the same name/version can keep exactly the same total size while one installed copy disappears and another appears elsewhere. A zero-byte delta shouldn't hide that change.
A useful fixture would move one identical copy between a nested dependency and the top level, then compare both snapshots. The grouped total stays flat, but the added/removed paths should remain visible. Your distinction between file bytes and reclaimable disk space is helpful here. Does the comparison also carry each scan's skipped-symlink warnings, so a quieter report isn't mistaken for a smaller install?