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