发布包

任何定义了导出的 Deno 程序都可以作为包发布，供其他开发者导入。本页介绍发布位置以及发布方式。

选择注册表 Jump to heading#

• JSR：推荐用于以 Deno 为优先的包的注册表。 它可直接接受 TypeScript（无需构建步骤），会根据你的 JSDoc 注释生成文档，并向 Deno、Node.js 及其他运行时提供包。
• npm：当你的使用者主要在 Node.js 上，或需要 npm 工具链时，请发布到这里。 使用 deno pack 从 Deno 项目构建与 npm 兼容的 tarball，或者使用 dnt 以获得更 可配置的构建流程。
• deno.land/x：用于 HTTPS 导入的旧注册表。对于新包，建议优先使用 JSR。

发布到 JSR Jump to heading#

在 deno.json 中为你的包指定名称、版本和入口点：

{
  "name": "@scope/my-package",
  "version": "1.0.0",
  "exports": "./mod.ts"
}

名称始终带有作用域（@scope/name）。首次发布时，请在 jsr.io 上创建该作用域。

检查将要发布的内容，然后执行发布：

deno publish --dry-run   # 验证文件列表和元数据
deno publish             # 打开 jsr.io 进行身份验证，然后发布

deno publish 会在上传前对你的代码进行类型检查，并验证你的导出不依赖 于包外的任何内容。有关标志，请参阅 deno publish 参考，有关作用域、版本控制、来源信息以及从 CI 发布，请参阅 jsr.io 上的发布包。

要在各个版本之间更新版本字段，你可以使用 deno bump-version。

发布到 npm Jump to heading#

deno pack（Deno 2.8+）会从 Deno 优先 项目构建与 npm 兼容的 tarball：它会转译 TypeScript、生成类型 声明，并生成 npm 期望的 package.json 元数据。

deno pack                # 创建 tarball
npm publish ./package.tgz

对于较旧的设置，或需要对输出进行细粒度控制的构建 （shims、多目标、构建期间运行测试），请使用 dnt，即 Deno 到 npm 的构建工具。

工作区 Jump to heading#

在 workspace 中，deno publish 会按依赖顺序发布 每个具有名称和版本的工作区成员。详细信息请参阅 将工作区包发布到注册表 。

自动化工作区发布 Jump to heading#

deno bump-version 可以驱动整个工作区的发布流程。在工作区 根目录下运行且不指定递增时，它会根据自上次 发布以来所做的 Conventional Commits 推断每个成员的版本变更，重写根导入映射中的 jsr: 约束以保持跨包 引用同步，并在 Releases.md 前追加一条变更日志条目。有关规则以及用于固定提交范围的标志，请参阅 根据 Conventional Commits 推断版本变更 。

Deno 标准库 将此功能接入 CI 作为可供你适配的参考。其 version_bump 工作流 运行 deno bump-version --import-map import_map.json，使用 deno fmt 格式化生成的 说明，然后提交结果并打开一个发布 PR，其中包含 各包的版本变更以及新的 Releases.md 条目。 合并该 PR 并发布 GitHub release 会触发第二个工作流，该工作流 为每个成员运行 deno publish，因此带标签的发布会直接流向 JSR， 无需手动编辑版本。

继续 Jump to heading#

• 依赖管理：本页所源自的日常工作流程
• deno publish 和 deno pack 参考
• JSR 发布文档