
1 xuanbg 2021-03-07 22:47:54 +08:00 Nexus 挺好用的 |
2 xuanbg 2021-03-07 22:50:37 +08:00 公共组件库的 release 版本应该有一定的稳定性,某个项目使用了某个版本,在没有升级需求前,应该不需要更新组件库的版本。 |
3 KuroNekoFan 2021-03-08 08:08:20 +08:00 via iPhone 既然提交了 lock,就应该用 npm ci |
4 kongkx 2021-03-08 09:31:13 +08:00 via iPhone 没看懂什么情况,ci 里面改 registry 然后进行 install,跟 本地跑 install 有什么区别吗 |
5 realtozf OP @xuanbg 用的就是 nexus 做私有仓库 抽取公共组件库的时候,抽取的过程中,需要安排一个项目版本去集成使用 达成出版本条件之后出个版本,这个过程必然会出发频繁的更新包的操作,但是版本不变的 @KuroNekoFan 每天构建的包会替换掉同版本的,sha1 是变化的 @xuanbg @KuroNekoFan @kongkx 感谢回复,我这边主要是想问问: 抽取 npm 库的完整流程有没有什么比较好的实践方案? 从确定需求->开发->其他项目集成->发布版本 这一整个流程,有没有什么标准的流程 |
6 KuroNekoFan 2021-03-08 12:54:56 +08:00 via iPhone monorepo 解千愁 |
7 realtozf OP @KuroNekoFan 哦豁,我研究研究看看是否适用 |
8 br_wang 2021-03-08 17:10:58 +08:00 对于一个组件库,「从确定需求->开发->其他项目集成->发布版本」中间的「其他项目集成」这步是指啥?其实你是想组件库发布和业务项目发布耦合在一起?还是仅仅是有个验证项目确保组件库更新的正确性? 基本上组件库除了单测外,都会有个 portal 或者 storybook 项目用来开发验证或展示用法。 |
9 realtozf OP @br_wang 毕竟不是大厂,没有那么多时间人力去搞...; 基本上就是有几个项目都有的共性需求,然后封装,在第一个版本封装的过程中,肯定是有个真实的项目去配合使用,并结合业务场景去提出问题改进; 每次版本的开发肯定是需要有业务项目一起耦合; 毕竟,内部的组件如果没有业务项目去使用,开发新版本就是在浪费人力 |
10 br_wang 2021-03-08 18:21:59 +08:00 @realtozf 也可以从业务项目向公共库抽取吧。这样可能质量和使用场景更有把控一些。支持当前项目后再向其他业务项目的场景扩展。 不然,先公共后业务,除非在开发前跟各方充分讨论,不然很容易产出脱离具体使用场景的「公共组件」。 |
11 xuanbg 2021-03-08 21:13:29 +08:00 snapshot 每次更新版本号,然后项目不锁版本不行吗? |
12 realtozf OP |
13 kongkx 2021-03-11 01:06:39 +08:00 via iPhone 听起来有点像 猪齿鱼 这个项目的集成方式。有点像 nightly build 的感觉。做个 cron ? ci install 前 先删除 lock ? 不过 package.json 要严格指明版本。 |