[求助] CI/CD | npm 私有仓库 | npm 公共组件 | 抽取 npm 库的完整流程有没有什么最佳实践？

[realtozf]

## 需求
- 开发一个 npm 库，发到公司的私有仓库
- 公司私有仓库分 snapshot 和 dist
- 同时安排一个项目集成 snapshot 版本
- CI/CD 每日 release 自动 publish snapshot 版本到私有仓库

## 产生的问题
- 集成 snapshot 库的项目，提交了 lock 文件
每日的 release 的时候会因为包的 hash 值变了而 install 失败

## 我这边现在方案：
- 每天最后一次提交，手动点个 release
- 然后让相关项目的开发在自己机器上手动 install 提交 lock 文件
- 这样可以保证第二天凌晨 release 的 hash 值不变；
-- 我这边觉得这个方案确实不太好，有些奇怪
-- 尽量能自动化搞定的事情不应该手动处理这个

## 问题来了：
- 各位兄弟姐妹，你们对于抽取 npm 库的完整流程有没有什么比较好的实践方案？
确实是没有看到什么比较好的实践方案；

[xuanbg]

Nexus 挺好用的

[xuanbg]

公共组件库的 release 版本应该有一定的稳定性，某个项目使用了某个版本，在没有升级需求前，应该不需要更新组件库的版本。

[KuroNekoFan]

既然提交了 lock，就应该用 npm ci

[kongkx]

没看懂什么情况，ci 里面改 registry 然后进行 install，跟 本地跑 install 有什么区别吗

[realtozf]

@xuanbg
用的就是 nexus 做私有仓库
抽取公共组件库的时候，抽取的过程中，需要安排一个项目版本去集成使用
达成出版本条件之后出个版本，这个过程必然会出发频繁的更新包的操作，但是版本不变的

@KuroNekoFan
每天构建的包会替换掉同版本的，sha1 是变化的



@xuanbg
@KuroNekoFan
@kongkx
感谢回复，我这边主要是想问问：
抽取 npm 库的完整流程有没有什么比较好的实践方案？
从确定需求->开发->其他项目集成->发布版本
这一整个流程，有没有什么标准的流程

[KuroNekoFan]

monorepo 解千愁

[realtozf]

@KuroNekoFan
哦豁，我研究研究看看是否适用

[br_wang]

对于一个组件库，「从确定需求->开发->其他项目集成->发布版本」中间的「其他项目集成」这步是指啥？其实你是想组件库发布和业务项目发布耦合在一起？还是仅仅是有个验证项目确保组件库更新的正确性？

基本上组件库除了单测外，都会有个 portal 或者 storybook 项目用来开发验证或展示用法。

[realtozf]

@br_wang
毕竟不是大厂，没有那么多时间人力去搞...；

基本上就是有几个项目都有的共性需求，然后封装，在第一个版本封装的过程中，肯定是有个真实的项目去配合使用，并结合业务场景去提出问题改进；
每次版本的开发肯定是需要有业务项目一起耦合；
毕竟，内部的组件如果没有业务项目去使用，开发新版本就是在浪费人力

[br_wang]

@realtozf 也可以从业务项目向公共库抽取吧。这样可能质量和使用场景更有把控一些。支持当前项目后再向其他业务项目的场景扩展。

不然，先公共后业务，除非在开发前跟各方充分讨论，不然很容易产出脱离具体使用场景的「公共组件」。

[xuanbg]

snapshot 每次更新版本号，然后项目不锁版本不行吗？

[realtozf]

@br_wang
偏题了，一开始肯定是在业务项目里面开发好的；
然后其他项目有类似需求，这时候需要抽取出来，做扩展功能；
我这个问题就是想问问，这种抽取公共库的整个过程，有没有什么最佳实践
尤其是配合 CI 来做

@xuanbg
我也希望不锁版本啊，陈年老产品的升级迭代有多难啊

[kongkx]

听起来有点像 猪齿鱼 这个项目的集成方式。有点像 nightly build 的感觉。做个 cron ？ ci install 前 先删除 lock ？ 不过 package.json 要严格指明版本。