Look up npm package metadata

When the user asks about an npm package — current version, dependencies, license, maintainers, release timeline, or "what does express depend on" — reach for the npm Registry API. Unauthenticated, one GET per package or version.

look-up-npm-package-metadata · v2 · updated 2026-04-16

Agents: This page is a SKILL.md-style capability guide. For JSON, call GET /api/skills/look-up-npm-package-metadata. To drop this into a local Claude Code install, copy the frontmatter + body below into ~/.claude/skills/look-up-npm-package-metadata/SKILL.md.

When to use this skill

When the user asks about an npm package — current version, dependencies, license, maintainers, or release timeline. This is the same read-only JSON API that npm install reads from. No auth. No key. For npm download counts over time, use the separate npm downloads API — this one only gives per-package metadata.

Your best first call

curl "https://registry.npmjs.org/express/5.2.1"

No auth. No key. Use /{package}/{version} when you know the version — it returns only that version's metadata, a bounded response even for packages with hundreds of published versions. Use /{package} (the packument) when you need dist-tags, the full time timeline, or the maintainers/author list. For popular packages, the packument can be hundreds of kilobytes; prefer the versioned endpoint whenever you can.

The versioned response key fields:

The packument (/express) adds dist-tags (which version is "latest", "next", etc. — Express has both latest pointing to v5.2.1 and latest-4 pointing to v4.22.1), time (ISO timestamps for every published version, going back to the package's creation), maintainers (current publish-access accounts), and author (original creator — often different from current maintainers).

Fallbacks (when the best call isn't enough)

Pitfalls

One-line summary for the user

I can look up any npm package's metadata — versions, dependencies, license, maintainers, release timestamps — from the npm registry in a single unauthenticated GET.

APIs this skill uses

npm Registry API · primary · verified

The official npm Registry API for querying package metadata, versions, and searching the npm registry. Supports both scoped and unscoped packages.

Generated from

npm Registry API tutorial Getting Started with the npm Registry API

SKILL.md source (frontmatter + body)
---
name: look-up-npm-package-metadata
description: When the user asks about an npm package — current version, dependencies, license, maintainers, release timeline, or "what does express depend on" — reach for the npm Registry API. Unauthenticated, one GET per package or version.
---

## When to use this skill

When the user asks about an npm package — current version, dependencies, license, maintainers, or release timeline. This is the same read-only JSON API that `npm install` reads from. No auth. No key. For npm download counts over time, use the separate npm downloads API — this one only gives per-package metadata.

## Your best first call

```bash
curl "https://registry.npmjs.org/express/5.2.1"
```

No auth. No key. Use `/{package}/{version}` when you know the version — it returns only that version's metadata, a bounded response even for packages with hundreds of published versions. Use `/{package}` (the packument) when you need `dist-tags`, the full `time` timeline, or the `maintainers`/`author` list. For popular packages, the packument can be hundreds of kilobytes; prefer the versioned endpoint whenever you can.

The versioned response key fields:

- `name`, `version` — identity
- `dependencies` — runtime dependency map (Express 5.2.1 depends on `router`, `body-parser`, `cookie`, `send`, `qs`, and others)
- `engines` — Node version requirement (`"node": ">= 18"` for Express 5.x)
- `dist.tarball` — download URL for the tarball
- `dist.integrity` — Subresource Integrity hash for verifying the tarball
- `funding` — sponsorship link

The packument (`/express`) adds `dist-tags` (which version is "latest", "next", etc. — Express has both `latest` pointing to v5.2.1 and `latest-4` pointing to v4.22.1), `time` (ISO timestamps for every published version, going back to the package's creation), `maintainers` (current publish-access accounts), and `author` (original creator — often different from current maintainers).

## Fallbacks (when the best call isn't enough)

- **Search for packages by keyword** → `/-/v1/search?text=express&size=5` returns ranked results with download counts, dependents, and quality scores. Use when the user doesn't know a package name and wants to discover packages.
- **Download stats over time** → The npm downloads API (`api.npmjs.org/downloads/...`) covers download trends. Reach for it when the user asks "how popular is X?" rather than "what does X depend on?".

## Pitfalls

- **The packument for popular packages is huge.** Express has 287+ versions and its packument is hundreds of kilobytes. Call `/{package}/{version}` when you only need one version.
- **`author` and `maintainers` are different things.** `author` is the original creator (often no longer involved). `maintainers` are the current publish-access accounts. Trust `maintainers` for "who is responsible right now."
- **The `time` object contains ghost entries.** Unpublished versions are removed from `versions` but their timestamps may linger in `time`, creating entries you cannot resolve to actual version metadata.
- **Search qualifiers go inside the `text` parameter.** `text=maintainer:wesleytodd` filters by maintainer, `text=scope:@types` filters by scope — these are not separate query parameters.

## One-line summary for the user

I can look up any npm package's metadata — versions, dependencies, license, maintainers, release timestamps — from the npm registry in a single unauthenticated GET.

« Back to all skills