各位前端同学，你们赞成 npm 包锁版本还是不锁版本呢？

[isbase]

锁版本

好处：稳定，yarn.lock 可以确保所有人安装的版本是一致的，不会出现一会儿正常一会儿错误的情况

坏处：

• 长年累月下来，开发同学为求稳定，部分依赖包长期停留在低版本，导致越到后面越难升级。
• 部分有漏洞的包发布紧急更新后需要开发者手动更新版本才能生效。

不锁版本

准确的说是不锁 minor 和 patch，只锁大版本，例如 ^1.x.x

好处：每次 npm install 都会拉取最新的 minor 和 patch 版本，利于依赖包提升新版本的普及率

坏处：不稳定，依赖包发版有几率导致项目挂掉，即使是 patch 版本，依赖包越多这个问题越严重

---

以及各位的公司在这方面都是怎么规定和建议的呢

[66beta]

看公司对于系统稳定性的要求了，如果但凡出点小问题，领导就要找你复盘，通报批评，还是锁死比较好

[leo108]

锁包+定期升版本不就完事了

[IvanLi127]

我觉得应该是得锁版本，然后定期更新。

[chenluo0429]

不是所有包的管理者都会在小版本递进的时候不引入破坏性的变更的, 所以我选择锁版本, 需要的时候手动更新

[yitingbai]

这还用讨论么, 正规项目肯定是锁版本啊, 定期更新库, 这样出问题的时候就知道是更新库导致的而不是代码 bug

[isbase]

@leo108
@IvanLi127

在大公司里，项目经手的人比较多，人员换来换去，后面的接手的开发人员，只要代码能跑起来，基本不会主动去升级依赖包。毕竟出问题要定责

[eason1874]

彻底锁死，每隔一段时间手动升级。

没吃过亏还有侥幸心理，吃过亏你就会彻底相信这样做是明智的。

[seki]

锁
不锁就等着各种奇怪的 bug 跑出来吧

[IvanLi127]

@isbase Leader 或者项目的技术负责人来搞呀。
说实话，如果真没人搞，那不更新就不更新吧。毕竟有些安全更新没人倒逼着跟进，那说明上层不重视。功能更新再另外想办法呗。

[Geo200]

不只是 npm，像 iOS 或 Android 这种前端，复杂的项目能锁就锁，已经经历过无数次前一天项目还是正常，第二天就发现项目跑不起来的情况，最后排查了半天才发现是某个模块升级导致的

[comoyi]

开发阶段不锁，提交测试前开始锁，之后就一直锁

[jim9606]

一般建议锁版本。

Google 曾经有一种项目管理的理念：所有活跃项目都使用主线版本，如果依赖升级导致 break，就作为一个 bug 处理，bug 最终都能修掉，追不上版本的项目就是死亡的项目。

因为这个理念，golang 相当长的时间里都没有官方的依赖版本管理方案，逼着所有项目追主线。不过现在还是转向 go mod 了，估计就是这种管理模式只适合 Google 那种求快速迭代不求稳定的业务模式。

[paopjian]

不怕 antd 那种埋彩蛋吗

[wyx119911]

锁版本久了可能会导致菱形依赖，后期项目就变成难以维护的屎山。
不锁版本平时就要投入更多的时间和人力去保证。

[netwjx]

必须锁

npm 上面包的质量你又不是不知道, 一定要锁

[Cbdy]

其实还是看公司的基础设施，如果有很好的测试和灰度发布机制，那么其实版本可以激进一点，反之还是锁版本，多一事不如少一事

我个人项目可是连 lock 文件都不加的😄

[duan602728596]

我可以做到定期更新依赖版本，定期删除不推荐使用的依赖（废弃的或者可以原生实现的），更新依赖时阅读依赖的更新说明，报错时可以找到问题的原因并回退版本等待修复或者参与修复。所以我不锁版本，避免留下屎山。

[renmu123]

锁，也不要 ignore package-lock 文件。不然出了 bug 或者依赖冲突就没救了

[mxT52CRuqR6o5]

锁了也可以手动更新，不锁的话如果有什么间接依赖升级导致出问题，这时候想锁就麻烦了
所以锁了好

[israinbow]

测试环境玩的跟 arch linux 一样, 生产环境高 1 个版本全项目组暴毙(