Dev & Engineering nodejsdependency-auditnpmpnpmbunnode-modulespublintmcp-server

Node Modules Inspector Dependency Audit Skill

Audit your project's installed node_modules: find duplicated packages, disk-space hogs, and dependencies with upgrade opportunities or publint issues.

FollowSkills review · FSRS-2.0
Recommended
67/ 100 5-point scale 3.4 / 5
1 2 3 4 5 6
1Trust20 / 25 · 4.0/5

SKILL.md describes read-only analysis of local node_modules with no registry writes, no credential access, no destructive operations; npm metadata fetching is config-gated and disclosed, and the on-disk cache location is documented. Deductions: the tool ships via npx from npm with unverified publisher identity, and the skill itself declares no confirmation/rollback mechanism.

2Reliability12 / 20 · 3.0/5

Internally consistent docs (CLI/MCP parity, explicit JSON shapes, stderr logging for pipe safety) plus a failure-modes section with interpretable feedback for three abnormal cases; the repo contains vitest tests (bun dependency-listing fixtures, module-type snapshots) and cross-platform CI. Deductions: static review did not execute; report subcommand outputs were not reproduced, and tests do not directly cover the report/mcp surface.

3Adaptability12 / 15 · 4.0/5

Trigger phrases and non-fit boundaries (explicitly excluding registry-only questions, bundle analysis, security audits) are exceptionally clear; supports pnpm/npm/bun. Deductions: docs are English-only with no Chinese support statement; reachability of npx/npm dependency fetching from mainland-China networks is unverified, and the maintainers report depends on npm metadata fetches that may be affected.

4Convention12 / 15 · 4.0/5

Good layering: frontmatter summary → table → per-report details → MCP → failure modes → Web UI progressive disclosure; clear MIT license, version 2.4.4, active CI, skill packaged via prepack with a defined update path. Deductions: no changelog evidence in provided files; some configuration details (experimental publint, config options) are deferred to jsdoc.

5Effectiveness7 / 15 · 2.3/5

Three reports with clear goals, complete JSON output shapes and options; clear marginal value over manually inspecting node_modules, with follow-up guidance like dedupe. Deductions: static review cannot verify outputs are directly usable; effectiveness claims lack executed evidence and are capped by the static ceiling.

6Verifiability4 / 10 · 2.0/5

The repo provides auditable primary material: MIT license, CI workflows, committed tests with fixtures covering core pipeline (dependency listing, module type). Deductions: tests do not cover the skill's key paths (report CLI/MCP tool outputs), static review could not independently reproduce, and cross-source corroboration is limited, so the score stays below the ceiling.

Evidence confidence:Low Reviewed Sep 09, 2026 Reviewed revision f5d3d6f458bf
The upstream repository has new commits since this review. The score still applies to the reviewed revision shown and may not cover the latest changes.
Before you use it
  • Nothing was executed: all report output shapes are documentation claims only; verify with report -- on a test project before relying on them.
  • The tool runs via npx as a third-party npm package; supply-chain integrity depends on npm distribution, and the publisher is not registry-verified.
  • The maintainers report fetches npm metadata and caches it in the user's home directory, which may be unreachable or slow from mainland-China networks; publint requires explicit config enablement.
  • Docs are English-only with no Chinese-language support declared; the online version (node-modules.dev) depends on WebContainer and may be unreachable on some networks.
Review evidence [1][2][3][4][5][6][7][8][9]
See the full review method →

What does this skill do, and when should you use it?

node-modules-inspector is an MIT-licensed open-source tool by Anthony Fu that inspects the node_modules actually installed on disk in the current project. It produces three structured reports: duplicates (packages installed in multiple versions), sizes (sorted by install size), and maintainers (dep-upgrade opportunities plus publint findings, grouped by consumer and author). It is available as a CLI (`npx node-modules-inspector report ... --`) or as an MCP stdio server exposing the same three tools, and works with pnpm, npm, and bun projects. The core analysis reads only the local filesystem; npm metadata enrichment for the maintainers report is gated behind config.

Reads the on-disk node_modules of the current project (resolved via pnpm/npm/bun lockfiles) and produces three reports: 1) duplicates: packages installed at multiple versions, defaulting to those with 2+ versions; 2) sizes: install size per package sorted by bytes descending, broken into fixed categories like js/dts/wasm, workspace packages excluded by default; 3) maintainers: grouped by package and GitHub author, listing dep-upgrade opportunities (declared range not satisfied by the highest installed version, with migration ratio) and publint findings (requires publint: true in config). Output defaults to an ANSI table; -- emits pure JSON to stdout with logs on stderr. Alternatively, npx node-modules-inspector mcp starts an MCP stdio server exposing the tools nmi:report-duplicates, nmi:report-sizes, and nmi:report-maintainers.

  1. A frontend developer whose node_modules has ballooned wants to know which packages consume the most disk before deciding what to clean up
  2. A pnpm project wants to verify it is safe to run `pnpm dedupe` by first checking which packages genuinely have multiple versions via the duplicates report
  3. A maintainer preparing an upgrade wants to see which consumers still declare outdated ranges and how far along their cohort's migration ratio is
  4. An open-source author wants to batch-check their maintained packages for publint warnings
  5. An AI coding agent expects multiple dependency queries in one session and uses MCP mode to read the dependency tree once and cache it across tool calls
  6. A CI pipeline needs a machine-readable dependency audit as a JSON artifact, piped through jq or similar

What are this skill's strengths and limitations?

Pros
  • Three reports share one analysis pipeline; CLI and MCP tools have identical input/output surfaces
  • Analysis runs against the real on-disk node_modules — basic reports need no registry calls, so results reflect exactly what's installed
  • Pipe-safe output: -- goes to stdout, logs to stderr, ready for jq
  • First run caches npm metadata on disk, making subsequent runs much faster
  • Supports pnpm, npm, and bun; MIT-licensed and authored by a well-known open-source maintainer (antfu)
Limitations
  • No yarn or other package managers — community-dependent support is still pending
  • Publint findings (and the full maintainers picture) require explicitly enabling publint: true in the config; off by default
  • Maintainers-report author data relies on package. author/maintainers fields and GitHub-handle detection, so it can be incomplete
  • Whole-monorepo analysis can be slow on very large repos; you must manually point --root at a single workspace package to speed things up
  • Not suited to registry-only questions, single-package bundle-size analysis, or security audits — those need different tools

How do you install this skill?

No standalone skill-folder install is required beyond copying skills/node-modules-inspector/ into your Agent Skills directory; if your project uses skills-npm, the skill is automatically symlinked into your agent's skill directory after installing the node-modules-inspector package. The underlying CLI runs on demand via npx/pnpx/bunx with no global install. Verify by running npx node-modules-inspector report duplicates -- in any project that already has node_modules.

How do you use this skill?

Run from a project root with dependencies installed; example agent prompts: "find duplicate packages in my node_modules" or "what's taking up disk space in node_modules?". Manual invocation examples: npx node-modules-inspector report duplicates -- | jq '.[].name'; npx node-modules-inspector report sizes -- --limit 20; npx node-modules-inspector report maintainers -- --sort migration. MCP mode: register npx node-modules-inspector mcp as a stdio server in your MCP client. Common options: --root <dir>, --config <file>, --depth <n> (default 8), --limit <n>. Running npx node-modules-inspector with no subcommand opens the human-facing Vue web UI on port 9999 — agents should use report/mcp instead.

How does this skill compare with similar options?

The README credits npmgraph as the project's main inspiration (an online npm dependency graph visualizer). The SKILL.md further steers registry-only questions to fast-npm-meta, security audits to npm audit or osv-scanner, and single-package bundle-size analysis to bundler-specific tools.

FAQ

Does it need network access?
The three core reports read only the local node_modules — no registry requests required. Only the npm metadata enrichment for the maintainers report fetches from the network, and that is gated by config. Metadata is cached on disk (~/.node-modules-inspector or similar) after the first run.
What does "No package manager detected" mean?
The project has no node_modules directory, or no pnpm/npm/bun lockfile was found. Run an install (e.g. pnpm install) first, then re-run the report.
The maintainers report came back empty — is it broken?
Not necessarily. An empty result usually means there are no dep-upgrade opportunities AND publint: true is not set in the config. If you expected publint output, enable it in node-modules-inspector.config.ts.
CLI or MCP mode — which should I use?
Prefer MCP when multiple queries are expected in one session (the tree is read once and cached across tool calls) or when structured output schemas matter; prefer `report ... --` when shell pipelining with jq or redirects is more convenient.

Related skills