Package License Viewer

Shows the license of every dependency inline, dimmed at the end of the line.

// package.json
{
  "dependencies": {
    "lodash": "^4.17.21",        // MIT
    "@babel/core": "^7.0.0",     // MIT
    "left-pad": "1.3.0"          // WTFPL
  },
  "devDependencies": {
    "typescript": "^5.7.2"       // Apache-2.0
  }
}

// deno.json
{
  "imports": {
    "@std/fs": "jsr:@std/fs@^1.0.0",   // MIT
    "chalk": "npm:chalk@^5.3.0"        // MIT
  }
}

Hover an annotation to see the resolved version, where the information came from, and a link to the package homepage.

How a license is resolved

1. The installed package, first. node_modules/<name>/package.json, walking up parent directories. Instant, works offline, and reflects the version that is actually installed.
2. The lockfile. Gives the exact pinned version even when nothing is installed yet. package-lock.json carries the license itself, so npm projects can resolve with no network access at all.
3. The registry. registry.npmjs.org for npm, jsr.io for JSR. Results are cached on disk for a week.

Specifiers that cannot be resolved — file:, link:, workspace:, git+…, user/repo, tarball URLs, https:// imports — are left un-annotated rather than marked unknown. npm: aliases are followed to their target. JSR packages inside package.json are recognized either way they show up — the npm-compatibility alias @jsr/scope__name, or the native jsr:<range> / jsr:@scope/name@<range> specifier pnpm ≥10.9 and Yarn ≥4.9 write directly — and routed to JSR automatically, since the npm-compatibility registry never publishes a license for them, installed or not.

The hover title links to the npmjs.org package page for dependencies that really are npm registry packages (following an npm: alias to its actual target), and to the matching JSR page for JSR packages — never to npmjs.org for those, since they aren't published there under their JSR or npm-compatibility name.

Package managers

Every layout below was verified by actually installing with that package manager.

So no per-package-manager branching is needed for the common case — the only real gap is Yarn PnP, which the lockfile layer covers. The same layer also handles a freshly cloned repository where npm install has not run yet.

Lockfile formats understood: package-lock.json (v1/v2/v3, including workspaces), npm-shrinkwrap.json, pnpm-lock.yaml (v5/v6/v9), yarn.lock (classic and berry), and bun.lock. bun.lockb is binary and is skipped — bun installs into node_modules, so that path covers it.

Commands

Settings

A note on JSR licenses

JSR only exposes a license for a version if the package declared one in its deno.json / jsr.json. Many packages have not, and for those the API returns null — the hover then says "the package declares no license on JSR". This is a gap in the published metadata, not in the lookup; nothing else in JSR's API carries the information (the npm-compatibility endpoint at npm.jsr.io does not include a license field either).

deno.lock is not read yet, so a jsr: range resolves against the registry rather than the version pinned in the lockfile.

Other languages

npm and JSR are covered today. Python (PyPI), Rust (crates.io) and Go are planned — the extension is built around a provider interface specifically so an ecosystem is one class away, without touching rendering, caching or scheduling. Every ecosystem is expected to link the hover title to its own registry page too, the same way npm and JSR already do. See CONTRIBUTING.md if you'd like to add one, or just want to see how it's structured.

Author

otoneko. https://github.com/otnc

License

MIT