npm Package Lens

Everything you need to know about a dependency, in package.json — what's outdated, what's blocked, and what's vulnerable — with one click to fix it.

Install from the VS Code Marketplace · Install from Open VSX

Features

Inline annotations

Every dependency gets an end-of-line annotation, colored to match its severity:

Peer dependency conflicts

Before an upgrade shows up as safe, it's checked against the peer requirements of everything else in the project — both what's installed in node_modules and what's declared in the manifest. If upgrading vite would break vite-plugin-sass-glob-import, you see that in the manifest rather than in a failed npm install.

The hover goes one step further and tells you whether the blocker's own latest release has relaxed its requirement — the difference between "upgrade both together" and "wait for upstream".

Vulnerability checks

Packages are checked against the OSV advisory database. Affected versions get a red squiggle in the editor and an entry in the Problems panel, with the advisory link and fix version on hover. Clicking an update that would move onto a version with a known advisory asks for confirmation first.

CodeLens version suggestions

Dependencies that need attention get their own row of clickable suggestions: what the declared range resolves to today, what it could be updated to, and two ways to take it — Update to 4.7.15 rewrites the specifier and saves the file, Install Update does that and runs the install step.

A blocked dependency gets a third option, since taking the newest version isn't the only sensible move:

🟡 Resolved as 9.39.5 | ✋ 10.8.0 blocked by 2 dependencies | Install Blocked Update

Resolved as pins the manifest to the version you already have — the safe action while a peer conflict stands. The other two take the blocked version anyway, which npm's --legacy-peer-deps and a coordinated upgrade both make reasonable. Editing several dependencies and installing once is the common case, so neither hides behind the other. Updates keep your range operator: ~1.2.3 becomes ~2.0.0, not 2.0.0.

Rows that are already on the newest version show nothing, so the suggestions mark out only what's worth acting on. Set npmPackageLens.codeLens.showUpToDate to true if you'd rather see them confirmed.

The V icon in the editor toolbar hides and re-shows them, for when you want the manifest uncluttered. Set npmPackageLens.codeLens.showOnStartup to false to start with only the section summaries.

The tag icon adds prerelease suggestions, optionally filtered to specific tags.

Each dependency section also gets a summary lens (▲ 5 updates available · 1 blocked), which is itself clickable to update everything in the file that isn't blocked.

Hover

Hover any dependency for update status, the installed-to-latest transition, monthly download count, description, deprecation notices, advisories, blockers, and links to npm, the repository, and the homepage.

Status bar

A summary of the active manifest (npm 5↑ 1✋ 2⚠), which turns amber when something is blocked or vulnerable. Click it to re-check.

Sidebar dashboard

A dedicated view grouping dependencies by section, with current and latest versions, a status badge, expandable blocker and advisory details, per-package Upgrade and ⇩ (upgrade and install) buttons, and bulk Upgrade all / Patches only actions. Clicking a package name jumps to its line in the manifest.

Commands

All commands are under the npm Package Lens category.

Settings

dependencyProperties defaults to dependencies, devDependencies, peerDependencies, optionalDependencies, overrides, overrides.*, resolutions, pnpm.overrides, pnpm.overrides.*, and the four jspm.* maps. A * segment matches any single property name. engines and the top-level packageManager field are always parsed.

How it works

Version comparisons are computed from the registry's dist-tags.latest against the range declared in package.json, using the same "which part changed" logic as npm-check-updates: the range operator is stripped from both sides, then the remaining version parts are diffed positionally. Packages on a 0.x major version are always flagged as a major-risk update, since semver makes no compatibility guarantee below 1.0.0. Non-semver specifiers (git URLs, workspace:*, file:, etc.) are left unannotated rather than guessed at.

Peer conflicts are evaluated with node-semver against the peer ranges of every top-level package in node_modules, plus the registry's peer data for anything declared but not installed. Optional peers are ignored, since npm won't fail an install over them.

Vulnerabilities come from OSV's batch API, queried for the version actually installed where node_modules can be read, and for the lowest version the declared range admits otherwise.

Architecture

src/
  extension.ts                 Activation: builds the analyzer, wires each feature to it
  config.ts                    Typed access to every contributed setting
  types.ts                     Shared domain types
  format.ts                    Relative-time formatting
  parse/
    package-document.ts        Pure manifest parser (offsets, not editor ranges)
  npm/                         No VS Code API usage, no UI concerns
    registry-client.ts         Registry documents, Zod-validated
    nodejs-releases.ts         Node.js LTS release lookup
    installed-packages.ts      Reads node_modules for installed versions and peers
    version-diff.ts            Specifier classification and bump severity
    suggestions.ts             Version suggestion lists
    peer-conflicts.ts          Which packages object to an upgrade, and why
    vulnerabilities.ts         OSV advisory lookup
  analysis/
    analyzer.ts                One pass: parse, fetch, analyze, cache, notify
  features/                    No direct fetches; every feature reads the analyzer
    presentation.ts            Status, colors, annotation text, summaries
    manifest-documents.ts      Manifest matching and offset-to-range conversion
    manifest-edits.ts          Specifier rewrites and section sorting
    dependency-decorations.ts  Inline end-of-line annotations
    hover-provider.ts          Hover UI
    code-lens-provider.ts      Version suggestions and section summaries
    diagnostics.ts             Advisory and deprecation squiggles
    status-bar.ts              Status bar summary
    panel-view.ts              Sidebar dashboard webview
    commands.ts                Every contributed command
    view-state.ts              Suggestion and prerelease visibility toggles

Every feature is a view onto one DependencyAnalyzer: it owns fetching, caching, and analysis, and emits a change event that each feature repaints from. That's what keeps a manifest's dependencies fetched once per cache window instead of once per feature.

Tests are split into two tiers, mirroring the npm/–features/ boundary:

test/
  unit/          Plain Node + Mocha, no Extension Host
    npm/         Registry, advisories, peers, suggestions, installed packages
    parse/       Manifest parsing
    features/    The pure presentation layer
  suite/         VS Code Extension Development Host
    features/    Anything that constructs real editor objects

test/unit runs in milliseconds via npm run test:unit since it never touches the vscode module at runtime. test/suite needs a real editor, so it launches through @vscode/test-electron.

Development

npm install
npm run compile       # tsc build
npm run watch          # tsc --watch
npm run test:unit      # fast: plain Node
npm test               # slower: compiles + launches an Extension Development Host
npm run test:all        # both tiers
npm run typecheck      # tsc --noEmit
npm run lint            # eslint (strict, type-checked, JSDoc-enforced)
npm run lint:fix
npm run format          # prettier --write
npm run format:check

All exported functions, classes, and types require a JSDoc block (enforced via eslint-plugin-jsdoc), and the TypeScript config runs with strict, noUncheckedIndexedAccess, and exactOptionalPropertyTypes enabled.

License

This software is released under MIT License