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

66beta

2021-08-03 11:34:49 +08:00

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

leo108

2021-08-03 11:40:54 +08:00

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

IvanLi127

2021-08-03 11:41:34 +08:00

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

chenluo0429

2021-08-03 11:42:22 +08:00

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

yitingbai

2021-08-03 11:46:05 +08:00

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

isbase

2021-08-03 11:46:20 +08:00

@leo108
@IvanLi127

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

eason1874

2021-08-03 11:50:22 +08:00

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

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

seki

2021-08-03 11:51:09 +08:00

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

IvanLi127

2021-08-03 11:58:46 +08:00

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

Geo200

2021-08-03 13:17:23 +08:00

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

comoyi

2021-08-03 13:32:51 +08:00

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

jim9606

2021-08-03 14:00:29 +08:00

一般建议锁版本。

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

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

paopjian

2021-08-03 14:20:00 +08:00

不怕 antd 那种埋彩蛋吗

wyx119911

2021-08-03 14:54:43 +08:00

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

netwjx

2021-08-03 14:55:56 +08:00

必须锁

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

Cbdy

2021-08-03 15:26:54 +08:00

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

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

duan602728596

2021-08-03 17:20:16 +08:00

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

renmu123

2021-08-03 17:27:32 +08:00

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

mxT52CRuqR6o5

2021-08-03 17:28:25 +08:00

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

israinbow

2021-08-03 20:33:14 +08:00

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