Live npm packages on your project site.

npm exposes two public APIs that matter for embeds. The npm Registry API at registry.npmjs.org returns package metadata: name, description, latest version, full version history, repository link, license, maintainers, dist-tags (latest, next, beta) and the deprecation flag. It is freely accessible without authentication and serves billions of requests every day, with package documents reachable at registry.npmjs.org/PACKAGE-NAME and version-specific documents at registry.npmjs.org/PACKAGE-NAME/VERSION. The downloads API at api.npmjs.org/downloads exposes daily, weekly and monthly download counts at point-in-time and over arbitrary date ranges (api.npmjs.org/downloads/point/last-week/PACKAGE-NAME and api.npmjs.org/downloads/range/2025-11-01:2026-05-08/PACKAGE-NAME). A serious npm widget calls both: Registry API for the card metadata and version history, downloads API for the weekly count and the 30-day sparkline. Poper proxies all calls through a global edge cache so your visitors never hit npm directly, which keeps your card rendered even when the registry has a hiccup.

Every JavaScript developer has internalized one number: weekly downloads. It is the universal heuristic for is this library real, is it being maintained, will it still exist in six months. The npm registry serves over 200 billion downloads per week across roughly 3 million published packages, and a card showing 5.7M weekly downloads next to npm install your-package converts visitors with a force that no marketing tagline can match. The number is also a defensible moat for your landing page: a static SVG shield from shields.io shows the count but cannot show the trend, and a screenshot is stale the day after you take it. A live widget that fetches from api.npmjs.org/downloads/point/last-week and re-renders on a six-hour cycle stays accurate without your effort. Pair it with a 30-day sparkline and you get the trend on the same card, which is what dev-tool buyers actually want to see when they evaluate a new SDK.

npm Inc. shipped the original Node package manager in 2010, and for a decade it was the only mainstream choice. Today the JavaScript install command is fragmented: npm itself ships with Node, Yarn (originally Facebook, now community-led under Yarn 4) holds a large share of monorepos and enterprise stacks, pnpm has become the default in the Vite, Vue and Astro communities thanks to its content-addressable store and dramatically faster installs, and bun (a Zig-based runtime + package manager + bundler) is the fastest-growing newcomer with first-class npm registry compatibility. Any modern install snippet on a JavaScript project page needs tabs for all four. Poper renders the npm install package, yarn add package, pnpm add package and bun add package commands in a single tabbed block with click-to-copy on each. Usage analytics tell you which command developers actually copy from your landing, which is the single best leading indicator of where your audience lives in the ecosystem.

The 2016 leftpad incident, when an 11-line utility was unpublished and broke half the JavaScript build pipelines on earth, permanently changed how the ecosystem thinks about supply chain. Every npm install pulls hundreds of transitive dependencies, and every dependent package is a trust decision. npm has since added unpublish protections, two-factor enforcement for high-impact packages, and most importantly, npm Provenance with Sigstore. Provenance attaches a signed attestation to every published version that proves which GitHub Actions workflow built and published the package, where the source code lived, and what command produced the artifact. The Provenance badge appears on npmjs.com next to packages that publish with it, and surfacing that signal on your own project page is a measurable trust lift for security-conscious buyers (think regulated industries, fintechs and the platform-engineering teams gating dependency policy). The Poper npm widget can render the Provenance verification chip and the Sigstore link on package cards, so your supply-chain hygiene is visible without forcing visitors to click through to npmjs.com.

JavaScript developers will Lighthouse your docs site, your landing page and your changelog. They will. It is half curiosity and half a screening signal: a project landing with a 95+ Lighthouse score reads as someone who actually cares about the craft, while a 60-score site with a janky badge embed reads as a project that does not eat its own dog food. Widgets are notorious Lighthouse killers: synchronous JavaScript blocking the main thread, layout shift from images that load late, blocking network requests to npm on every visit. The Poper npm widget is engineered for this audience: async loading below the fold, scoped CSS that cannot leak into your design system, edge-cached responses so visitors never hit npm directly, dimensions reserved on every element to keep CLS at zero, and the entire bundle gzipped under 40KB. Embed it on a Docusaurus, Nextra, Astro Starlight or Next.js docs site and your Lighthouse score will not move. That matters more for a JavaScript project than for any other vertical, because your audience is the one running the audit.