npmx.dev: a browser for the npm registry that keeps npmjs.com URLs working

The gap npmx.dev targets: registry data that is hard to link to

The npm registry is the source of truth for packages, and npmx.dev does not try to become a second one. The README states the goal plainly: "We're not replacing the npm registry, but instead providing an elevated developer experience through a fast, modern UI." That framing matters, because it tells you what kind of project this is. It is a read-mostly front end with an admin layer bolted on, not a package manager.

The problem it addresses is navigational. On a typical day you look up a package, check its versions, open the repository, read the README, inspect a dependency that moved between two releases, and then try to send a colleague a link to the exact thing you found. npmx.dev makes each of those states a URL. The README lists URL-driven feature views for exact package versions, search results, compare sets, source files and lines, diffs, docs, changelogs, stats and timelines. A permalink to a specific source line is the clearest example: on a plain registry page that state does not exist as an address.

The audience is anyone who reads packages more than they publish them, plus maintainers who manage access. The README describes an "enhanced admin experience" for managing packages, teams and organizations from the browser, and says it is "powered by your local npm CLI". That is the detail to hold onto: the admin side is not a server-side credential store, it runs through tooling you already have installed.

How the Nuxt app is put together and where the data comes from

The repository is a pnpm workspace with a Nuxt application at the root and a separate docs package. The top-level layout shows app/, server/, shared/, modules/, i18n/, lexicons/, cli/ and test/ directories, plus nuxt.config.ts, uno.config.ts and a pnpm-workspace.yaml. The package.json sets "type": "module" and marks the package private, so this is an application, not a published library you would import.

Several mechanisms are visible from the file list rather than from prose. The i18n/ directory and the README's claim of 39+ locales line up, and two UnoCSS presets, uno-preset-a11y.ts and uno-preset-rtl.ts, sit at the root, which is consistent with accessibility and right-to-left support being treated as build-level concerns rather than per-component fixes. A scripts/ directory holds compare-translations.ts and remove-unused-translations.ts, so locale drift is checked by script. The lexicons/ directory and lexicons.json, generated during postinstall, point at AT Protocol lexicon definitions, which fits the social features the README describes such as liking packages and a most-liked leaderboard.

Data flow is the part the README leaves thinnest. It names OSV for security advisories and lists GitHub, GitLab, Bitbucket, Codeberg, Gitee, Sourcehut, Forgejo, Gitea, Radicle and Tangled as sources for stars and forks, but it does not describe caching, rate limiting or what happens when an upstream provider is slow. Treat that as an open question if you plan to self-host under load.

Installing npmx.dev locally and opening a package view

The README points at the hosted site rather than giving a setup walkthrough, so the install path comes from the repository files. The workspace uses pnpm, and the package.json defines the standard Nuxt scripts. A postinstall hook runs lexicon and sprite generation, then nuxt prepare for both the app and the docs package, so the first install does real work and is slower than a bare dependency fetch.

pnpm install
pnpm dev

The dev server is `nuxt dev`, started through the dev script. Nuxt's default port is 3000, though the repository does not state a port for the app itself; the only port in package.json is 3001, and that belongs to the docs package via `dev:docs`. If you want to run the documentation site alongside the app, that is the second command to reach for.

pnpm dev:docs

Before starting the server, copy .env.example to .env and fill in both values. The file defines exactly two variables, and the comments say each can be generated with `openssl rand -hex 32`.

NUXT_SESSION_PASSWORD=""
NUXT_IMAGE_PROXY_SECRET=""

The first is described as a secure session password and the second as an HMAC secret for image-proxy and OG image URL signing. The README does not explain what breaks if either is left blank, so generate both rather than testing your luck.

For a first real use, the highest-value feature to try is the version diff. Pick a package you depend on, open two versions, and check whether the source and dependency changes are legible at the granularity you need. The second is the code viewer with a permalink to a specific line, because that is the view you will paste into a pull request. If neither beats your current habit of reading the repository on the code host, the rest of the feature list is unlikely to change your mind.

Admin features depend on your local npm CLI, not a hosted login

The README's admin list is long: grant package access, revoke team access, add and remove package owners, add and remove organization members, change roles, create teams, manage team membership. The sentence that governs all of it is the one about the local npm CLI. Whatever authentication and authorization happens, it flows through tooling on your machine rather than through an account you create on npmx.dev.

That design has a clear upside. Your registry token stays where your npm client already keeps it, and the browser is a control surface rather than a credential holder. It also means the admin experience is not a remote service you can hand to a colleague who has not set up npm locally. If your team's mental model is "open the website, log in, click around", the admin half of npmx.dev will not match it.

The repository also contains a cli/ directory and a package.json script named `npmx-connector` that runs `vp run --filter npmx-connector dev`, with a sibling `mock-connector` script for a mock variant. The README does not document what the connector does or how it pairs with the browser. Anyone relying on the admin features should read the cli/ directory directly, because the README stops short of explaining the handshake.

Where npmx.dev falls short: dependents, self-hosting and a thin README

The comparison table in the README is unusually honest, and the honesty is useful. The dependents list is marked with a construction symbol on the npmx.dev side while npmjs.com has it. If reverse-dependency lookup is part of your workflow, npmx.dev is not yet the tool for that job, and no amount of speed elsewhere compensates.

The README is also a feature catalogue more than a manual. It does not document deployment, caching, rate limits against the registry or the code hosts, or how the multi-provider repository support degrades when a provider is unreachable. For the hosted site at npmx.dev that is fine. For a self-hosted instance it is the difference between a weekend project and an operational commitment. The presence of vercel.json suggests the maintainers deploy on Vercel, but the README does not present that as a supported path for others.

Maintenance signals are healthy on paper. The last push was on 2026-09-23, the repository is not archived, and the recent releases run v0.17.1 on 2026-07-17, v0.18.0 on 2026-08-18 and v0.19.0 on 2026-09-12. That is a roughly monthly cadence across three releases, with a version number still below 1.0. A pre-1.0 version number is a real signal here: it means the maintainers reserve the right to change things, and the README does not document rollback or an upgrade path between releases. Pin a commit if you fork it.

npmx.dev versus npmjs.com: different jobs, not just different speeds

The obvious alternative is npmjs.com itself, and the difference is not only interface speed. npmjs.com is the registry's own front end, which means it is the canonical place to publish, manage tokens and read the authoritative package record. npmx.dev reads that registry through a different lens and adds views the registry site does not have: package comparison, version diff, changelog view, timeline view, generated API docs, install size calculation, and warnings for outdated dependencies, install scripts and license changes.

If what you need is to publish a package or manage a token, npmjs.com is the right tool and npmx.dev is the wrong one. If what you need is to decide whether to take on a dependency, npmx.dev's comparison and timeline views are doing work that the registry site does not attempt. The URL compatibility trick makes this cheap to test: the README says you can replace npmjs.com with xnpmjs.com or npmx.dev in any URL and it works. That means you can keep your existing bookmarks and muscle memory and only switch for the views that add something.

A second alternative, for the code-reading half of the job, is the package's own repository on GitHub or GitLab. That gives you the real history, issues and pull requests. npmx.dev's code viewer and diff are conveniences layered on published tarballs, not a replacement for the repository. Reading a diff between two published versions is a different question from reading the commit history that produced them, and only one of those tools answers each.

Licence and the cost of keeping a fork current

The project is MIT licensed, and package.json carries "license": "MIT" with the author listed as Daniel Roe. MIT is permissive: you can fork, modify and redistribute, including commercially, provided the copyright notice and permission notice travel with the code. There is a LICENSE file at the repository root. This is a description of the licence text, not legal advice; if you are embedding the code in a product, have your own counsel read it.

The practical cost is not the licence, it is the dependency surface. This is a Nuxt application with UnoCSS, Storybook, Playwright, Lighthouse configuration, a Chromatic config, Codecov, Knip, Renovate and a patches/ directory for patched dependencies. A fork inherits all of that. Renovate is configured, which helps upstream, but a fork that stops pulling will drift, and a patched dependency in patches/ is exactly the kind of thing that breaks quietly on an upstream bump.

The upgrade cadence to plan around is the one the releases show: roughly monthly, with a minor version bump each time. Following that is cheap if you track main and rebuild. Falling a few releases behind is where the pre-1.0 status starts to hurt, because there is no documented migration guide and no stated rollback procedure in the README. If you self-host, decide up front whether you are tracking upstream or freezing a commit, because the repository does not make that decision for you.

Editorial conclusion

Adopt npmx.dev if you spend a lot of time jumping between the npm website, a code host and a diff tool, and you want those views addressable by URL. Do not adopt it if you need a dependents list today, since the comparison table marks that row as still in progress, or if you expect the hosted site to sign you in without a local npm CLI. Before self-hosting, verify what the .env.example secrets actually gate, because the file defines only NUXT_SESSION_PASSWORD and NUXT_IMAGE_PROXY_SECRET and the README does not document rollback or a migration path between releases.

Frequently asked questions

Official sources

1. License: MIT
2. npmx-dev/npmx.dev on GitHub
3. Project website
4. README
5. Releases