废话不多说，直接上流程，同时也是一份 检查清单，👇🏼
-
确定在主分支上；
-
确定分支是干净的，包括处理掉要合并到主分支的全部分支；
-
提升版本；
-
生成更新日志；
-
副作用：重新生成依赖锁、依赖列表等文件，重新构建等，这里可以自由安排做很多事，但都与发版有关，以便将操作结果捆绑最新版本号；
-
以版本号作为提交信息，将所有修改推送至远程仓库；
-
打上 Git 标签，并推送至远程仓库；
-
可选：将更新日志的内容发布到仓库的 Git 标签说明中；
-
发布到包管理器。如果本地配置了使用 非 NPM 官方仓库，在发包时得指定 NPM 官方仓库，
npm publish --registry=https://registry.npmjs.org。
🤤
到此这个检查清单就结束了。看上去，不仅仅适用 NPM 发包，是不是，😬。（所以最后一步我没有声明具体哪款包管理器）
类似的事情，我一般都会有一份可以直接实操的完整步骤，让我完全不用去思考，直接照着做。最怕着手一件不同的事情时，打断当时解决问题的思路、分散注意力。这也就要求这个操作步骤是经得起考验的，也确实经得住考验，我每一次都可以无脑照做，几乎没发生什么问题。
或者，也可以使用 现有的 NPM 发包工具，一般情况下，使用这些工具挺好的，不过这些工具内部的流程无法从外部变更，所以搞清楚这些工具的内部流程，也就是上述步骤，特殊情况下按需手动操作，这是最灵活的。有更多的方式选择，何乐不为呢。
我打算自己写个实现上述流程的发包工具，暴露钩子函数（或生命周期）以供灵活调控，并适用日常、DevOps 操作，完成后会更新到这偏帖子中，不过目前还在作品储备中，完全没动工，哈哈哈，😃。
打算将我的笔记都以文章的形式发布出来，与大家分享，更多（80%）还是想交流，集思广益，另外也想结识些志趣相投的新朋友，好朋友，🫵🏼，我知道你就在那儿，快联系我吧！😬（微信：iyoooooooo）
👣
