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 1
对于一个组件库,「从确定需求->开发->其他项目集成->发布版本」中间的「其他项目集成」这步是指啥?其实你是想组件库发布和业务项目发布耦合在一起?还是仅仅是有个验证项目确保组件库更新的正确性?
基本上组件库除了单测外,都会有个 portal 或者 storybook 项目用来开发验证或展示用法。 |
9
realtozf OP @br_wang
毕竟不是大厂,没有那么多时间人力去搞...; 基本上就是有几个项目都有的共性需求,然后封装,在第一个版本封装的过程中,肯定是有个真实的项目去配合使用,并结合业务场景去提出问题改进; 每次版本的开发肯定是需要有业务项目一起耦合; 毕竟,内部的组件如果没有业务项目去使用,开发新版本就是在浪费人力 |
10
br_wang 2021-03-08 18:21:59 +08:00 1
@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 要严格指明版本。
|