Features everyone should steal from npmx

Andrew Nesbitt's April 2026 post on npmx — Daniel Roe's alternative frontend to npmjs.com launched in January 2026 — makes two arguments at once. First, competitive pressure from a usable alternative actually moves incumbents: npmjs.com had been frozen under GitHub ownership for years, then shipped long-dormant dark mode shortly after npmx took off. Second, the feature set npmx shipped is worth reading as a spec for what a modern package registry should expose, regardless of which registry you're building.

The alternative-frontend-pattern is what made the launch work at all. Invidious did it for YouTube, Nitter for Twitter; npmx applies the same URL-swap trick to npmjs.com, and nugx.org has already cloned the pattern for NuGet. Any existing npmjs.com URL works by swapping the hostname to npmx.dev, which makes bookmarks, browser extensions, and muscle memory carry over with zero per-user migration work.

The feature catalog

Nesbitt lists 17 features, grouped here by theme. Each has a working MIT-licensed reference implementation in the npmx repo and, in most cases, prior art elsewhere in package-registry land.

What you're actually installing

• Transitive install size — unpacked total including dependencies, not the tarball size crates.io and PyPI show. Bundlephobia and packagephobia have done this for JavaScript for years.
• Install script disclosure — preinstall / install / postinstall scripts rendered on the package page with links into the source browser, including any npx packages those scripts would fetch. Supply-chain hygiene: most compromises start in a postinstall hook.
• Outdated and vulnerable dependency tree — expandable tree where each node is annotated with how far behind latest it is and whether it's in OSV. Google's deps.dev does this cross-ecosystem.
• Version range resolution — every ^1.0.0 range shows the concrete version it resolves to right now.

Ecosystem and toolchain fit

• Module format and types badges — ESM/CJS/dual badge, bundled-types vs @types/*, declared Node engine range. Crates.io's MSRV field is the same spirit.
• Module replacement suggestions — packages in the e18e module-replacements dataset get a banner pointing to the native API or lighter alternative, with MDN links where relevant.
• Cross-registry availability — scoped packages that also exist on JSR are flagged. The general idea ("this is also on registry X") applies to any overlapping ecosystems, and doubles as a dependency-confusion check.
• Multi-forge repository stats — star/fork counts from GitHub, GitLab, Bitbucket, Codeberg, Gitee, Sourcehut, Forgejo, Gitea, Radicle, and Tangled, based on the repository field rather than hardcoding GitHub.

Comparing versions and packages

• Side-by-side package comparison — up to 10 packages in a table plus a traction/ergonomics scatter plot.
• Version diffing — any two published versions diffed file-by-file in the browser. Hex has had diff.hex.pm for years; cargo-vet gives Rust a similar capability.
• Release timeline with size annotations — every version on a timeline marked where install size jumped. Useful for spotting the release where someone accidentally started shipping test fixtures.
• Download distribution by version — break the weekly download chart down by major/minor line. RubyGems shows per-version counts as a table; npmx renders as a distribution.

Integration and ergonomics

• Command palette — ⌘K for every page action and global navigation. On a package page, typing a semver range filters the version list to matches. Borrowed from editors, not registries.
• Internationalisation — 30+ locales including RTL. Warehouse (PyPI) is the only other registry doing this seriously.
• Accessibility as a default — long-form aria-label on charts and demo videos, screen-reader-friendly palette, dedicated accessibility statement.
• Playground link extraction — StackBlitz / CodeSandbox / CodePen / JSFiddle / Replit links from READMEs pulled into a dedicated panel.
• Agent Skills detection — packages containing Anthropic Agent Skills manifests have them listed with declared tool compatibility. "Very 2026," per Nesbitt, but the general idea of detecting non-code payloads in published packages generalises.

Social layer without a silo

• ATProto-backed social features — likes as atproto records, Bluesky threads for comments, custom record types as public lexicons in the repo. This is the workaround for running a social layer on a registry without owning the moderation problem: borrow an existing identity/content network. Nesbitt notes skepticism about long-term Bluesky infrastructure dependency but acknowledges npmx runs its own PDS at npmx.social as a hedge.

Auth that doesn't require registry credentials

• Local-CLI admin connector — claim a package, edit access, etc. is proxied through the user's local npm CLI rather than requiring login to npmx. Elegant sidestep: npmx doesn't need to hold credentials for a registry it doesn't own.

The one npmjs.com already copied

• Dark mode and custom palettes — listed last because npm has shipped it, joining pkg.go.dev, crates.io, and PyPI.

Why this article matters

As a design reference, the list is reusable — any package registry UI (Go, Python, Rust, Maven, NuGet, Hex) can pick items off it. As a story, the ATProto-for-social and local-CLI-for-auth patterns are the non-obvious moves: both solve "we don't own the backend" problems without losing functionality to that constraint. And the npmjs.com-shipped-dark-mode anecdote is a small but concrete data point for when alternative frontends move incumbents.

Related

• nesbitt-io — author's blog (second post ingested)
• npmx — the tool itself
• alternative-frontend-pattern — the URL-swap pattern that made this launch work
• git-magic-files — earlier Nesbitt post in the wiki
• open-source-security-astral — adjacent: supply-chain-hygiene tooling from the registry-operator side