在 GitHub 收购 npm 的大部分时间里，npmjs.com 这个面向公众的网站实际上处于冻结状态，问题追踪器中积压了数年的请求却无人关注。1 月份，丹尼尔·罗（Daniel Roe）创建了 npmx.dev 作为同一注册表数据的替代前端，并在 Bluesky 上发布后，短短两周内积压多年的需求便转化为该仓库中实际会被合并的千余个问题和拉取请求，贡献者数量也在几天后突破百人。好在所有 npmjs.com 的 URL 只需将主机名替换为 npmx.dev 或 xnpmjs.com 即可使用——这正是 Invidious 和 Nitter 所用的技巧，因此浏览器扩展和肌肉记忆都能无缝迁移。竞争压力似乎奏效了：上个月 npmjs.com 推出了深色模式，这是问题追踪器中五年来得票最高的特性请求，同时也有迹象表明其他长期停滞的工单正在被重新处理。
无论这种趋势是否持续，npmx 已成为构建包注册网站的有用创意库，且整个项目采用 MIT 许可，而 npm 注册表和官网仍闭源，因此以下每个功能都配有可运行的参考实现，而非仅提供截图。若存在其他生态系统的先例也会予以说明。
传递安装大小。显示的是包及其所有依赖项解压后的总大小——即实际写入磁盘的内容，而非 crates.io 和 PyPI 所展示的单个 tarball 文件大小。JavaScript 开发者多年来一直通过 bundlephobia 和 packagephobia 获取这一数据。安装脚本披露。清单中的任何 preinstall、install 或 postinstall 脚本都会在包页面展示，并附带这些脚本会调用的 npx 包链接，还可直接跳转到代码浏览器查看其内容。鉴于许多供应链事件都始于 postinstall 钩子，这项功能尤为重要。过时与存在漏洞的依赖树。不同于平铺直叙的声明依赖列表，这里以可展开的树形结构呈现，每个节点均标注其与最新版本的差距以及是否在 OSV 中存在漏洞，并递归追溯传递依赖。谷歌的 deps.dev 在其他生态系统中也有类似做法。版本范围解析。每当出现类似 ^1.0.0 的 semver 范围时，页面上会同时显示其当前解析到的具体版本，省去你通过 CLI 查询的往返操作，方便你了解实际会得到哪个版本。模块替换建议。若某包出现在 e18e 模块替换数据集中，页面会显示横幅提示指向原生 API 或更轻量的替代方案，并为原生情况提供 MDN 链接。模块格式与类型徽章。包名旁会标明 ESM、CJS 或双模式，以及 TypeScript 类型是已打包还是需要单独安装 @types/* 包，同时还会显示声明的 Node 引擎版本范围。虽然细节针对 JavaScript，但“此包能否兼容我的工具链”这类徽章的理念具有普适性；crates.io 的 MSRV 字段和 edition 徽章也秉持相同思路。多平台仓库统计。星标和分叉数量会根据 repository 字段指向的位置，分别从 GitHub、GitLab、Bitbucket、Codeberg、Gitee、Sourcehut、Forgejo、Gitea、Radicle 和 Tangled 获取，而非仅特殊处理 GitHub。跨注册中心可用性。若某个作用域包在 JSR 上也存在，则会特别标注出来。这种 npm/JSR 的配对关系专属于 JavaScript，但“此内容也在注册中心 X 上”这一表述适用于任何生态重叠的场景，例如 Maven 和 Clojars，或各种 Linux 发行版的软件仓库。当名称在其他地方也存在，但发布者不匹配时，相同的查询也可用于依赖混淆检查。并排包对比。最多可同时加载十个包进入对比视图，该视图以表格形式展示上述所有指标，并附带一个散点图：横轴为聚合“牵引力”（traction），纵轴为“易用性”（ergonomics），从而直观区分出热门但臃肿与小巧但不知名的选项。版本差异比对。浏览器中可逐文件对比任意两个已发布版本，Hex 多年来一直通过 diff.hex.pm 提供此功能，而在 Rust 世界中则通过 cargo-vet 工具实现类似功能。带大小标注的版本时间线。每个包的版本都会绘制在时间线上，并在安装包体积显著增长的位置添加标记——这是一种巧妙的方式，能一眼发现某个版本中有人意外开始打包测试夹具的情况。按版本的下载分布。可将每周下载图表按主版本或次版本拆分，从而清晰看到当前 v5 的生态中有多少仍停留在 v2，这与 RubyGems 的每版本下载统计类似，但呈现方式更直观，以分布图而非表格形式展现。命令面板。⌘K 呼出一个面板，包含当前页面上的所有操作及全局导航；在包页面中输入 semver 范围即可过滤版本列表中的匹配项。此设计借鉴自编辑器及 GitHub，而非来自任何注册表。国际化支持。界面支持三十多种语言，包括 RTL（从右到左）语言，PyPI 的 Warehouse 是另一个投入此领域的注册中心。默认无障碍设计。发布说明中的图表与演示视频均配有详细的 aria-label 和 figcaption 文本，命令面板兼容屏幕阅读器，并设有专门的无障碍声明。游乐场链接提取。自动从包的 README 中提取 StackBlitz、CodeSandbox、CodePen、JSFiddle 和 Replit 等链接，并集中展示于独立面板，用户无需克隆即可直接尝试。Agent 技能检测。包含 Agent Skills 清单文件的包会列出其声明的工具兼容性——这颇具 2026 年风范，尽管检测已发布包中的非代码载荷仍有实用价值。AT Protocol 社交功能。包的“点赞”以 atproto 记录形式存储，而非存入私有数据库；博客评论线程即为 Bluesky 线程；自定义记录类型作为公共词汇表公开于代码库，使其他工具无需与 npmx 通信即可读写相同数据。若你曾想为注册表添加评论或评分功能却对维护另一套审核体系望而却步，借用现有网络的标识与内容层不失为一种合理方案。虽然我个人怀疑长期依赖 Bluesky 的基础设施是否可行，但至少 npmx 在其 npmx.social 上运行自己的 PDS，无论怎样这些记录都由其掌控。本地 CLI 管理连接器。诸如认领包名或编辑访问权限等管理操作，将通过本地 npm CLI 代理执行，无需登录网站，从而避免 npmx 需为不拥有的注册表保存凭据的问题。深色模式和自定义调色板。之所以放在最后，是因为 npm 现在也实现了这一功能，与 pkg.go.dev、crates.io 和 PyPI 一样。.NET 领域已经有人实现了类似功能：nugx.org 自称“受 npmx 启发”，正在为 NuGet 做同样的事情。