大家好,这里是大家的林语冰。
public npm registry,意思是"公共 npm 注册表/注册中心",它是一个收集 JS 软件包的数据库,每个软件包都由软件和元数据组成。
我们可以发布自定义模块到 npm 注册表,向整个社区或其组织成员贡献软件包,我们也可以从 npm 注册表下载社区中的各种模块。
npm 默认使用 registry.npmjs.org 作为注册表。出于网速或开发体验考虑,我们也可以将 npm 配置为自己喜欢的注册表,比如淘宝源、腾讯源、桃花源等。
npm 注册表的模块实现了 CJS(CommonJS)规范,抛开安全性不谈,它既支持 CJS 模块,又兼容 ESM 模块,这常常让初来乍到的 npm 用户一脸懵逼。
如果有更简洁的、只支持 ESM 标准规范模块的注册表,那该多好啊!
本期共享的是 ------ Deno 最新推出的 JSR,完全拥抱 ESM 模块的注册表。
免责声明
本文属于是语冰的直男翻译了属于是,略有删改,仅供粉丝参考。英文原味版请传送 Introducing JSR - the JavaScript Registry。
JSR 简介
JSR,全称 JS 注册表(JS registry),现已进入 beta 公测版!JSR 针对 TS 优化,能且仅能支持 ESM 模块。JSR 支持 Deno 和基于 npm 的项目(包括 Node、Bun 等),免费且开源。
我们可以像这样安装软件包:
bash
# npm 或其他类 npm 系统
npx jsr add axios
# deno
deno add axios
我们也可以像导入任何其他 ESM 模块一样导入包:
js
import axios from 'axios'
我们还可以从命令行轻松发布自己的 JS/TS 模块:
bash
# 类 npm 系统
npx jsr publish
# deno
deno publish
模块会作为 TS 源码发布到 JSR。API 文档生成、类 Node 环境的类型声明,以及转译均由 JSR 处理。模块作者可以只需关注编写 TS。
JSR 的背景与由来
JS 已成为地表最强的编程语言。JS 在浏览器、移动设备、机器人和服务器上运行,我们可以使用 JS 进行几乎所有编程。
Node 是过去 15 年这一转变的主要缘由,但谈论 Node 的成功就不能不提及 npm 同样令人喵瞪狗呆的成功。在过去的短短一个月里,npm 就拥有超过 250
万个软件包和约 2_500
亿次下载,npm 名副其实是地表最强的软件包注册中心。
如果没有 JS 社区共建的这个令人喵瞪狗呆的生态系统,JS 可能不会有今天的霸主地位。这应该成为 npm 上每个模块作者的骄傲。
从 2009 到 2024,自 npm 首发以来,JS 的世界日新月异。
- ESM 模块已成为编写可重用 JS 代码的 Web 标准,取代了 CJS。
- TS 不仅成为一种通过编译时类型检查编写 JS 的方案,且成为 TC39 最新 JS 语言功能的测试平台。
- Node 不再是浏览器之外唯一相关的 JS 运行时。Deno、Bun 等运行时正在开发体验上推陈出新,严格遵循 Web 标准,权衡设计以在边缘服务器上快速启动。
虽然 npm 仍然是当今 Web 开发的基础组件,但其设计并没有考虑到这些新的现实。我们认为是时候重新构思 2024 软件包注册表的工作方式了。
- 它应该接受 ESM 作为 JS 模块的 Web 标准
- 它应该优先考虑为 TS 设计
- 它应该简单快速,且提供优秀的开发体验
- 它应该是免费开源,且可以在 JS 能跑的任意地方奏效
- 它应该建立在 npm 的成功之上,而不是复刻它
为了实现这些设计目标,我们十分鸡冻地共享 JSR(JS 注册表)。从今天开始,JSR 可以在 beta 公测版中免费访问。
使用 JSR 的模块
在 JSR 的主页上,我们可以按名搜索模块,也可以根据包描述搜索。
举个栗子,我们搜索 http serve
,找到了 Oak,它是来自 deno.land/x 的人气爆棚的 HTTP 中间件框架之一,已经发布在 JSR 上。
粉丝请注意,每个包都有一个与其关联的质量评分。评分由多因素决定,比如文档的完整性、用于快速类型检查的最佳类型声明,以及与多个运行时的兼容性。
找到正确的模块后,可以在该模块自动生成的 API 参考文档的页面顶部找到安装和使用说明。
举个栗子,我们在 Node 项目中使用 Oak。在终端中,初始化一个新的 Node 项目,并使用以下命令安装 Oak:
bash
npm init --yes
npx jsr i @oak/oak
发布到 JSR
作为软件包创建者,JSR 让我们的生活更加轻松。我们可以使用 TS 编写包,并将 TS 源码直接发布到 JSR,而无需构建步骤。
要了解 JSR 的工作流程,我们可以创建并发布一个名为 yassify
的自定义模块,这个模块的功能是在字符串文本后插入某些表情符号。
构建 yassify
包时,首先在终端中,创建一个名为 yassify
的文件夹,并在其中创建三个文件:
jsr.json
:软件包的元数据文件mod.ts
:模块的集体实现(名字任意,比如xx.ts
)README.md
:一个 markdown 文件,将用作jsr.io
上模块的概述
在 jsr.json
中,包含有关我们的软件包的下述元数据:
json
{
"name": "@xxx/yassify",
"version": "1.0.0",
"exports": "./mod.ts"
}
上述元数据包括:
name
属性,包含了软件包的作用域@xxx
和名称yassify
- 软件包的
version
:使用语义版本控制安装 JSR 包,并删除重复数据 exports
字段,指定软件包中的哪些模块可供消费者使用
在 README.md
中,包含某些高级使用说明和软件包示例。举个栗子:
md
# yassify
欢迎使用 `yassify` 对任意文本字符串应用有趣的表情过滤器。
## License
MIT
然后,在 mod.ts
中实现 yassify
函数:
ts
/**
* 附加表情的字符串
*
* @param str 待处理的文本字符串
* @returns a 添加了表情的字符串
*/
export function yassify(str: string): string {
return `${str} 💅✨👑`
}
最后,创建完三个文件后,我们可以从命令行发布模块,使用下述命令:
bash
# 类 node 环境
npx jsr publish
# deno
deno publish
如果这是我们首发此模块,系统可能会提示我们为其创建作用域和包名称。
点击"Create"按钮会提示最终授权检查:
稍后,我们的软件包就会发布到 JSR!
如果我们访问软件包页面,就会注意到我们创建的 README
文件充当该软件包的主页。我们还会注意到已为软件包自动生成了 TS API 文档。
针对我们软件包导出的函数和符号,文档是根据源代码和注释生成的:
我们还可以在 Settings
选项卡下辅助潜在用户了解哪些运行时支持我们的模块。我们可能还想在这里配置模块的说明,相关描述也会显示在搜索结果中。
花时间更新也会提高软件包的综合质量评分。yassify
的功能可能比较鸡肋,但也有详细记录!
这是我们作为软件包发布者需要做的所有事情,让我们瞄一下作为消费者使用这个软件包的体验又是如何。
在项目中使用我们的软件包
创建 Node 项目,接受所有默认选项,安装所有 npm 依赖。
创建项目后,我们可以使用以下命令安装刚刚创建的 yassify
模块,根据需要替换自己的作用域名称:
bash
npx jsr add @xxx/yassify
在文件顶部,添加 yassify
的导入,如下所示:
js
import { yassify } from '@xxx/yassify'
如果您使用的是 VS Code,请将鼠标悬停在 yassify
导入上。粉丝请注意,编辑器中已提供内联文档!
这是因为 JSR 已自动转换模块中的 TS 代码,并包含 .d.ts
文件,这些文件为编辑器提供有关模块如何工作的提示。按住 Command 键单击 yassify
函数,我们会在项目的 node_modules
文件夹中看到 .d.ts
文件:
最后,我们可以在项目中使用 yassify
函数!如下所示:
html
<h2>{yassify(title)}</h2>
我们可以使用以下命令,启动本地开发服务器预览:
bash
npm start
从 GitHub 发布
虽然从命令行发布对于尝试而言一切顺利,但我们可能希望从 CI(持续集成)发布软件包。在 JSR 设置的极简方案是链接 GitHub 存储库。在 JSR 包 Settings
UI 中,配置存储包源码的 GitHub 用户名和存储库名称。
链接 GitHub 仓库后,将以下配置添加到 .github/workflows/publish.yml
下的文件中:
yml
name: Publish
on:
push:
branches:
- main
jobs:
publish:
runs-on: ubuntu-latest
permissions:
contents: read
id-token: write # 用于 JSR 权限验证的 id token
steps:
- uses: actions/checkout@v4
- run: npx jsr publish
将此文件推送到 GitHub 存储库后,进一步提交到 main
分支,当它们包含新版本时会自动发布到 JSR。
通过这种方式发布还可以让您的用户放心,它们项目中包含的工件确实是从 CI 上传的,并且有来源透明日志可供查看。
辅助我们提升 JS 生态系统水平
虽然 Deno 团队在 JSR 上呕心沥血,但我们希望 JSR 成为一个公共工具,造福整个 JS 生态系统。这就是我们基于 MIT 许可免费开源 JSR 的原因。我们设计的 JSR 对于任何用户而言都相对容易托管。
JS 和 Web 平台很可能在未来几年仍然是强势霸榜的编程环境。我们希望 JSR 能够推动 JS 社区未来的创新,并辅助 JS/TS 开发者解放生产力,无论其代码在哪里运行。
本期话题是 ------ 你更常用 ESM 还是 CJS 模块,或者发布过哪些好用的 npm 模块吗?
欢迎在本文下方自由言论,文明共享。谢谢大家的点赞,掰掰~
《前端猫猫教》每日 9 点半更新,坚持阅读,自律打卡,每天一次,进步一点。