这是一个创建于 1190 天前的主题，其中的信息可能已经有所发展或是发生改变。
锁版本
好处：稳定，yarn.lock 可以确保所有人安装的版本是一致的，不会出现一会儿正常一会儿错误的情况
坏处：
- 长年累月下来，开发同学为求稳定，部分依赖包长期停留在低版本，导致越到后面越难升级。
- 部分有漏洞的包发布紧急更新后需要开发者手动更新版本才能生效。
不锁版本
准确的说是不锁 minor 和 patch，只锁大版本，例如 ^1.x.x
好处：每次 npm install 都会拉取最新的 minor 和 patch 版本，利于依赖包提升新版本的普及率
坏处：不稳定，依赖包发版有几率导致项目挂掉，即使是 patch 版本，依赖包越多这个问题越严重
以及各位的公司在这方面都是怎么规定和建议的呢
 |
1
66beta 2021-08-03 11:34:49 +08:00
看公司对于系统稳定性的要求了，如果但凡出点小问题，领导就要找你复盘，通报批评，还是锁死比较好
|
 |
2
leo108 2021-08-03 11:40:54 +08:00  1
锁包+定期升版本不就完事了
|
 |
3
IvanLi127 2021-08-03 11:41:34 +08:00
我觉得应该是得锁版本，然后定期更新。
|
 |
4
chenluo0429 2021-08-03 11:42:22 +08:00
不是所有包的管理者都会在小版本递进的时候不引入破坏性的变更的, 所以我选择锁版本, 需要的时候手动更新
|
 |
5
yitingbai 2021-08-03 11:46:05 +08:00
这还用讨论么, 正规项目肯定是锁版本啊, 定期更新库, 这样出问题的时候就知道是更新库导致的而不是代码 bug
|
 |
6
isbase OP |
 |
7
eason1874 2021-08-03 11:50:22 +08:00
彻底锁死，每隔一段时间手动升级。
没吃过亏还有侥幸心理，吃过亏你就会彻底相信这样做是明智的。 |
 |
8
seki 2021-08-03 11:51:09 +08:00
锁
不锁就等着各种奇怪的 bug 跑出来吧 |
|
9
IvanLi127 2021-08-03 11:58:46 +08:00
@isbase Leader 或者项目的技术负责人来搞呀。
说实话，如果真没人搞，那不更新就不更新吧。毕竟有些安全更新没人倒逼着跟进，那说明上层不重视。功能更新再另外想办法呗。 |
 |
10
Geo200 2021-08-03 13:17:23 +08:00
不只是 npm，像 iOS 或 Android 这种前端，复杂的项目能锁就锁，已经经历过无数次前一天项目还是正常，第二天就发现项目跑不起来的情况，最后排查了半天才发现是某个模块升级导致的
|
 |
11
comoyi 2021-08-03 13:32:51 +08:00
开发阶段不锁，提交测试前开始锁，之后就一直锁
|
 |
12
jim9606 2021-08-03 14:00:29 +08:00 1
一般建议锁版本。
Google 曾经有一种项目管理的理念：所有活跃项目都使用主线版本，如果依赖升级导致 break，就作为一个 bug 处理，bug 最终都能修掉，追不上版本的项目就是死亡的项目。 因为这个理念，golang 相当长的时间里都没有官方的依赖版本管理方案，逼着所有项目追主线。不过现在还是转向 go mod 了，估计就是这种管理模式只适合 Google 那种求快速迭代不求稳定的业务模式。 |
 |
13
paopjian 2021-08-03 14:20:00 +08:00
不怕 antd 那种埋彩蛋吗
|
 |
14
wyx119911 2021-08-03 14:54:43 +08:00
锁版本久了可能会导致菱形依赖，后期项目就变成难以维护的屎山。
不锁版本平时就要投入更多的时间和人力去保证。 |
 |
15
netwjx 2021-08-03 14:55:56 +08:00
必须锁
npm 上面包的质量你又不是不知道, 一定要锁 |
 |
16
Cbdy 2021-08-03 15:26:54 +08:00
其实还是看公司的基础设施，如果有很好的测试和灰度发布机制，那么其实版本可以激进一点，反之还是锁版本，多一事不如少一事
我个人项目可是连 lock 文件都不加的😄 |
 |
17
duan602728596 2021-08-03 17:20:16 +08:00
我可以做到定期更新依赖版本，定期删除不推荐使用的依赖（废弃的或者可以原生实现的），更新依赖时阅读依赖的更新说明，报错时可以找到问题的原因并回退版本等待修复或者参与修复。所以我不锁版本，避免留下屎山。
|
 |
18
renmu123 2021-08-03 17:27:32 +08:00 via Android
锁，也不要 ignore package-lock 文件。不然出了 bug 或者依赖冲突就没救了
|
 |
19
mxT52CRuqR6o5 2021-08-03 17:28:25 +08:00
锁了也可以手动更新，不锁的话如果有什么间接依赖升级导致出问题，这时候想锁就麻烦了
所以锁了好 |
 |
20
israinbow 2021-08-03 20:33:14 +08:00
测试环境玩的跟 arch linux 一样, 生产环境高 1 个版本全项目组暴毙(
|
 |
21
ianva 2021-08-03 20:36:31 +08:00
不锁版本，你 CI/CD 的时候构建的版本敢上线？
|
 |
22
leafre 2021-08-03 20:42:01 +08:00
锁 生产稳定第一，早收工早下班
|
 |
23
clickhouse 2021-08-03 21:25:37 +08:00
锁，有需求的话可以单独更新版本提交测试。
|
 |
24
wenzichel 2021-08-03 22:01:50 +08:00
锁版本，即使版本低，但每个组件组合起来，是能正常运作的，万一某个组件拉取的是最新版本，可能会造成多个组件的不兼容，连启动都启动不起来。
|
 |
25
yhxx 2021-08-03 23:48:19 +08:00
锁，甚至为了防止第三方不锁，连依赖一起打包
|
 |
26
aaronlam 2021-08-04 01:38:21 +08:00
我们公司目前是不锁版本，如果出问题也只能人肉排查。
我个人感觉也还是锁版本比较稳当，这样就可以定期进行一次阶段性的升级，如果某些包出现安全问题的时候再进行紧急的升级，这样至少能保证出问题的几率是在可控范围之内。 |
 |
27
shiny 2021-08-04 01:48:15 +08:00
package-lock 进版本控制，CI 的时候使用 npm ci 。版本变更是独立的 commit，谁修改谁负责。
|
 |
28
sutra 2021-08-04 02:03:28 +08:00
历史上好像有好几回因为没有锁死版本而出的政治、宗教方面的生产事故了。
|
|
29
sutra 2021-08-04 02:05:37 +08:00
比如 Ant Design 圣诞节彩蛋事件。
|
 |
30
xupefei 2021-08-04 04:52:18 +08:00 via iPhone
指望小版本保持兼容性就是扯淡，我用过一个 python 包在一个+0.0.1 的版本里去掉了整个 python3.5 支持，搞得我负责的项目挂了一整天。
|
 |
31
lerry 2021-08-04 10:16:54 +08:00
锁版本，彻底锁死，谨慎升级，因为真的吃过亏
|
Select Language