此页面记录了 Nodemon 如何管理其发布流程，包括版本控制策略、工具以及从代码更改到 npm 包发布的自动化管道。有关向 Nodemon 贡献代码更改的信息，请参阅 贡献指南。
Nodemon 使用由 semantic-release 和 GitHub Actions 驱动的自动化发布流程。这种方法消除了手动版本升级和变更日志生成的需要，同时确保基于约定式提交消息的一致版本控制。
发布流程会自动
来源: package.json41-42 .github/workflows/release.yml
当推送到 main 分支或 main 分支上的测试成功完成时，将自动触发发布流程。这确保了只有通过所有测试的代码才能发布。
来源: .github/workflows/release.yml2-10 .github/workflows/node.js.yml4-10
Nodemon 遵循语义化版本控制 (SemVer) 原则，其中版本号结构为 MAJOR.MINOR.PATCH
实际版本号由 semantic-release 根据自上次发布以来的约定式提交消息自动确定。
在 package.json 中，版本设置为 "0.0.0-development"，这是一个占位符，semantic-release 将在发布过程中替换它。
来源: package.json70 commitlint.config.js
Nodemon 使用 Conventional Commits 规范的提交消息，并通过 commitlint 执行。此标准通过将提交消息与语义版本增量关联，帮助自动化发布流程。
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
常见的提交类型包括
| 类型 | 描述 | 版本影响 |
|---|---|---|
feat | 新功能 | MINOR |
fix | 错误修复 | PATCH |
docs | 文档更改 | 无 |
style | 代码样式更改（格式化等） | 无 |
refactor | 代码重构，无行为更改 | 无 |
perf | 性能改进 | PATCH |
test | 添加/修复测试 | 无 |
chore | 构建过程或工具更改 | 无 |
在类型后添加 !（例如，feat!:）或在页脚添加 BREAKING CHANGE: 表示重大更改，这将触发 MAJOR 版本升级。
来源: commitlint.config.js package.json33-34
Nodemon 使用 GitHub Actions 自动化测试和发布流程。涉及两个主要工作流：
测试工作流 (.github/workflows/node.js.yml)：在每次推送到 main 和 pull 请求时运行
发布工作流 (.github/workflows/release.yml)：在 main 分支测试通过时或直接推送到 main 分支时运行
来源: .github/workflows/release.yml .github/workflows/node.js.yml
发布完成后，会创建以下构件
用户随后可以通过 npm 安装该包
来源: package.json1-75 .github/workflows/release.yml23-29
发布流程需要特定的环境变量才能正常运行
| 环境变量 | 目的 |
|---|---|
GITHUB_TOKEN | 与 GitHub API 身份验证以创建发布 |
NPM_TOKEN | 与 npm 注册表身份验证以发布包 |
这些令牌存储为 GitHub 存储库机密，并在工作流中安全访问。
来源: .github/workflows/release.yml26-28
如果发布失败，最常见的问题是：
对于出现故障情况下的手动干预，需要具有适当权限的团队成员