Node Modules Inspector: a UI and CLI for auditing what is actually in node_modules

What Node Modules Inspector is for

The README opens with a plain description: "Visualize your node_modules, inspect dependencies, and more." That sentence covers the web UI, and the rest of the document extends the scope to shell pipelines and AI coding agents. The tool targets a specific frustration: an installed dependency tree is opaque even when the lockfile is readable. You can see that a package is present, but not which of your direct dependencies pulled it in, how many copies of it exist, or how much disk space the copies consume.

It is not a package manager and it does not install anything. The README says it currently supports pnpm, npm and bun projects, and explicitly notes that other package managers depend on community contributions. That boundary matters: if your repository resolves with yarn, the documented support does not cover you.

The audience is narrow but real. Library authors who publish packages and want to know what consumers will end up installing. Application teams whose bundles or CI install times have grown and who suspect duplicate versions. Agent users who want dependency data in a machine-readable form rather than a screenshot.

How the inspector reads a project

The repository layout shows a monorepo with a packages/ directory and a root package.json whose scripts delegate into packages/node-modules-inspector. The root manifest declares type: module, a packageManager field pinned to pnpm, and Node engines of ^22.19.0 || ^24.11.0 || >=26.0.0. So the published package is TypeScript, ESM-only, and expects a modern Node runtime.

The inspection itself produces a static SPA or a live UI from the current node_modules state. The README's static build section says the build command produces a .node-modules-inspector folder that you can host with any static file server, which implies the analysis runs locally and emits data the UI consumes, rather than the UI querying a remote service. The online version at node-modules.dev is described as powered by WebContainer, meaning the analysis happens in the browser instead of on your machine.

Credits give one concrete implementation detail: the module type detection algorithm comes from wooorm/npm-esm-vs-cjs. That is the part that decides whether a package is ESM or CJS, and it is borrowed rather than invented here. The README does not document the resolution algorithm beyond this, so treat the classification as best-effort.

Installing Node Modules Inspector and running a first report

There is no install step. The README's Quick Start runs the package directly with whichever runner matches your project, so nothing is added to your dependencies. Run it under a pnpm, npm or bun project:

npx node-modules-inspector

The same command appears as pnpx and bunx variants. It starts the interactive UI against your current node_modules. Because the package is not a dependency, there is no lockfile entry to clean up afterwards.

For a static artifact you can host, the README gives a build subcommand. Running it writes a .node-modules-inspector folder:

npx node-modules-inspector build

The README says that folder can be served by any static file server, which is how the author publishes a build for all of his packages at everything.antfu.dev.

For pipelines, the report subcommands are the practical entry point. The README documents three, and the JSON flag keeps stdout clean because progress logs go to stderr:

npx node-modules-inspector report duplicates --json | jq '.[].name'
npx node-modules-inspector report sizes --json --limit 10
npx node-modules-inspector report maintainers --json --sort migration --no-latest-only

Common options across the reports are --root <dir>, --config <file>, --depth <n> and --limit <n>, and the README points to node-modules-inspector report --help for the per-report flag set. If you want an agent to consume the same data, the MCP server runs over stdio:

npx node-modules-inspector mcp

It exposes nmi:report-duplicates, nmi:report-sizes and nmi:report-maintainers, with schemas derived from valibot definitions and surfaced through tools/list.

Configuration is a TypeScript file, and that is the whole story

Behaviour is configured through node-modules-inspector.config.ts in the project root. The README's example imports defineConfig and sets defaultFilters.excludes, defaultSettings.moduleTypeSimple and an experimental publint flag that defaults to false:

import { defineConfig } from 'node-modules-inspector'

export default defineConfig({
  defaultFilters: {
    excludes: [
      'eslint',
    ],
  },
  defaultSettings: {
    moduleTypeSimple: true,
  },
  publint: true,
})

The README defers the rest to JSDoc rather than listing options, so the config surface is discoverable only through the type definitions. That is a deliberate trade-off: the file is typed and validated, but you cannot learn the available keys from the README alone. Note the excludes example is a filter on what the UI shows, not a way to keep packages out of the analysis.

The publint integration is labelled experimental, which is a fair signal. If you enable it and get surprising results, the README has already told you where the stability boundary sits.

Where Node Modules Inspector stops being the right tool

Package manager coverage is the first hard limit. The README states support for pnpm, npm and bun, and says other package managers are left to the community. A yarn repository is outside the documented path.

The second limit is the Node engine requirement. The repository's package.json declares ^22.19.0 || ^24.11.0 || >=26.0.0. If your CI image or local runtime is on an older Node line, the tool will not run there, regardless of what your project itself supports. That is an unusual constraint for a diagnostic tool, since the projects most likely to need dependency auditing are often the ones pinned to older runtimes.

The third is that this is a read-only inspector. It reports duplicates and sizes; it does not deduplicate, prune or rewrite your lockfile. If your actual goal is a smaller install, the report tells you where to look but the fix happens in your package manager or your dependency ranges.

Finally, the README documents no rollback or undo behaviour for the static build output, because there is nothing to undo: the build writes a folder. The README also does not document what the inspector does with workspaces or monorepo boundaries beyond the --root and --depth options.

How it differs from npmgraph and pkg-size.dev

The README credits npmgraph as the main inspiration and links pkg-size.dev for running analysis with installations in WebContainer. The difference in approach is worth stating plainly.

npmgraph draws a dependency graph in the browser from package metadata. Node Modules Inspector inspects what is actually installed on your machine, which is why it can report install sizes and duplicate versions present in your specific tree rather than in a hypothetical resolution. That is a meaningful distinction: a graph from metadata shows what could be installed, while this shows what is.

pkg-size.dev installs packages inside a WebContainer to measure their size. Node Modules Inspector also offers a WebContainer-backed online version, but its local mode reads your existing node_modules instead of performing a fresh install, so the numbers reflect your resolution and your lockfile.

The MCP server is the clearest divergence from both. Neither npmgraph nor pkg-size.dev exposes dependency reports as agent tools, and the README positions the three reports explicitly for shell pipelines and AI coding agents.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-16. Three releases landed the same day: v2.6.1, v2.6.2 and v2.7.0, with the root package.json declaring version 2.7.0. That cadence suggests the release line moves quickly, which cuts both ways: fixes arrive fast, and a pinned version can fall behind within days.

The licence is MIT, stated in the README and in the LICENSE file. MIT permits commercial use and modification with attribution and no warranty, but this is a description of the licence text, not legal advice for your situation.

The upgrade cost is low by design. Because the README's Quick Start runs the package through npx, pnpx or bunx rather than adding it to dependencies, there is no version bump to schedule. If you do pin it in CI, the surface you depend on is the report subcommands and their JSON output, plus the config file. The README documents --json and the pipe-safe stderr split but does not promise schema stability across versions, so a pinned version plus a parse check is the safer arrangement than tracking the latest release.

Editorial conclusion

Adopt Node Modules Inspector if you maintain a pnpm, npm or bun project and need to see duplicate versions, install sizes or upgrade candidates without reading lockfiles by hand, and if you want the same data exposed to an agent through the MCP server. Do not adopt it for yarn, for other package managers the README says are unsupported, or as a replacement for a package manager's own resolution logic. Before relying on it, verify that the report command runs against your project root and that the JSON output parses, since the README documents --json and pipe-safe stderr but not the full schema stability.

Frequently asked questions

Official sources

1. antfu/node-modules-inspector on GitHub
2. License: MIT
3. Project website
4. README
5. Releases