这是一个创建于 751 天前的主题，其中的信息可能已经有所发展或是发生改变。
 | 1 NessajCN 2023-09-19 14:20:08 +08:00  1 除了必须升级 node 版本以外的所有情况 |
 | 2 julyclyde 2023-09-19 14:22:07 +08:00 对社会进步感觉恐惧的时候 |
 | 3 enpitsulin 2023-09-19 14:24:33 +08:00 团队他人的能力完全 cover 不住任何技术迭代所带来的任何问题的时候，老老实实 nvm use 14 就得了。大家都是赚口饭钱没啥必要 |
 | 4 IvanLi127 2023-09-19 14:25:37 +08:00 via Android 项目年久失修的情况下 |
 | 5 wu67 2023-09-19 14:28:52 +08:00 项目依赖导致升不上去了. 不维护升级的话, 这个项目基本的所有依赖就锁死版本上限了, 后续想要升级都不敢动, 最后变成山, 只能推倒重来 例如我们的 nuxt2 项目, 好家伙, 直接锁死在 16.14.2, 再高一点点都跑不起来, 其他项目我都升到 18.17.1 了, 就这个不敢动也没法动... |
 | 6 weekidjoker OP @wu67 #5 就是部分依赖不支持高版本的 node ？ |
 | 7 Zhuzhuchenyan 2023-09-19 15:00:20 +08:00 比如老旧项目，升级不如重写， 我司现在有 - 两个 Angular 6 的项目，Node v12 - 两个 Angular 8 的项目，Node v14 - 三个 Angular 13 的项目，Node v16 |
| 8 Zhuzhuchenyan 2023-09-19 15:01:41 +08:00 纠正一下上文，检查了一个 Angular 6 和 8 的项目，Node 版本是 8 和 10 （掩面） |
 | 9 AV1 2023-09-19 15:09:17 +08:00 当你接手一个依赖 sass 的项目时。 |
 | 10 zackzergzeng 2023-09-19 15:09:48 +08:00 1 小项目随便，大项目 node 升级带来的破坏改动传导到依赖升级，依赖升级带来的破环改动传导到项目本身，然后项目本身兼容这些破环性改动的带来的 bug 和测试成本，算算成本和毛利率基本就放弃了…… |
 | 11 darkengine 2023-09-19 15:15:43 +08:00 没有时间的时候 |
| 12 weekidjoker OP 看来我接触的项目还是不够老 |
 | 13 babyoung 2023-09-19 15:37:12 +08:00 1 能用 |
 | 14 a632079 2023-09-19 16:40:17 +08:00 @weekidjoker #6 依赖 webpack 4 ，webpack 4 使用了旧版 OpenSSL 的接口。webpack 4 貌似使用了 md4 ，无法适配新的 openssl 接口。 其次，nuxt2 ，vue-cli （这货弃用前还能更 webpack5 ） 都直接弃用了，要么加参数，要么就只能摆烂了。 |
 | 15 duan602728596 2023-09-19 16:51:18 +08:00 让不会 node 的人搞基建，就会成这个样子 |
 | 16 LitterGopher 2023-09-19 16:52:26 +08:00 暂时无法联网的时候。 |
| 17 weekidjoker OP @a632079 #14 那新需求能用的依赖都不支持低版本的 node ，怎么办 |
| 18 a632079 2023-09-19 17:24:43 +08:00 @weekidjoker #17 因此 Node 有 node 版本管理器啊。比如说 NVM 、N 、PNPM 自带的 env 。 你可以把这个理解成 python 的虚拟环境，不过这个本质更简单，只是改了下 PATH 中 node 的位置。 P.S 三个里面 n 应该是最好用的，全局包是共享的，但是可能会引入版本冲突问题（如果你往全局赛的不只是 cli tool ） |
| 19 weekidjoker OP @a632079 #18 我知道有版本管理工具，我的意思是在一个低版本 node 才能跑的项目中，某一天要加新功能，而这个功能用到的依赖不支持低版本 node ，这时候要怎么处理？ |
| 20 a632079 2023-09-19 17:36:15 +08:00 @weekidjoker #19 看看库的老版本支不支持，不支持的话只能换别的库、找 polyfill 或者转义（尤其是针对新的 ES 语法，譬如 JS 的 private field ）、要么就是自己移植。 --------- 这种坑蛮多的，比如说 chalk ，got 这种：node 现在掀起了一股重写成 esm 的潮流老的 CommonJS 项目，要么找个转义器，比如说 babel ；要么就是用他的旧版本；要么就是花时间换别的库替代。 |
 | 21 liuidetmks 2023-09-19 17:36:16 +08:00 @enpitsulin hahaha 我们 node8 webpack 1.x ，没人想改。npm install 都无法成功，必须通过特殊手段安装。 |
 | 22 adoal 2023-09-19 17:42:13 +08:00 1 说到底就是成本和收益的权衡。有很多屎山业务系统，用的基础组件已经爆出很多严重安全漏洞了，但就是不去更新。因为安全问题并不一定真的会导致事故，但把业务系统更新挂了又修不好那可是要丢饭碗的。 |
| 23 adoal 2023-09-19 17:45:02 +08:00 1 现实中有很多程序员在对用到的 library/SDK/API/whatever 理解不到位的情况下，发现实际由于 bug 导致的测试行为跟文档不一致，并不会意识到是 bug ，而是凭着瞎猜各种补来补去搞定，还自以为有了新经验。这种你要是去升了，fix bug 了，人家依赖 bug 行为而写的业务系统铁定挂掉。 |
| 24 weekidjoker OP @adoal #23 所以定位 bug 的能力也挺重要的 |
 | 25 guiling 2023-09-19 18:16:52 +08:00 开发环境：nvm 随便改 生产环境：非必要不更新 |
 | 26 7inFen 2023-09-19 19:07:19 +08:00 无所谓，就算升到 v20 还是会用`npm install --legacy-peer-deps` |
 | 27 Ming5Ming 2023-09-19 19:22:43 +08:00 能用就别升了吧, 何必折腾呢, 万一崩了还得自己去修 bug  |
 | 28 roundgis 2023-09-19 20:17:21 +08:00 via Android 古老目 |
 | 29 MaxFang 2023-09-19 23:21:02 +08:00 如果不升级，项目跑不了，那升级；如果升级可以加薪，那升级。否则，都不升级。 |
 | 30 libook 2023-09-20 11:11:32 +08:00 1 patch 版本通常都会修复 bug 和安全漏洞的，所以一般能升就升。 minor 版本通常会引入新特性，或积累比较多的更新，出了一个 minor 之后就不会出上一个 minor 的 patch ，所以一般能升就升。 major 版本通常有支持周期的，如果过了周期也就不会有修复 bug 或安全更新了，所以最好随时保证 major 版本仍有更新支持。其他的就是看依赖包是不是兼容，像 gyp 包就有可能跟 major 版本强相关，node 过新可能编译失败。 当然不管什么时候给项目升级，都要做好测试，最好能灰度发布看一看；这个不论是升级 node 还是升级依赖还是升级系统环境都是一样的。 |
 | 31 zhongs 2023-09-20 17:02:45 +08:00 代码层面，新版本废除了一些老版本的 API |
 | 32 Torpedo 2023-09-20 22:40:30 +08:00 服务端一般不升。但是打包比如 webpack 总是尽量升 |
 | 33 LokiSharp 2023-10-23 02:25:54 +08:00 via iPhone 没有写单元测试就不升级，写了完善的测试就修改到可以全 PASS 为止 |
 | 34 wangtian2020 2023-11-07 17:09:43 +08:00 升不上去的时候，选择不升级 node 版本。 核心业务跑在 Ubuntu 16 上，实在是升不上去各种依赖缺失。 试了几个版本用不了，最终用的 nodejs 最新的 v16 ，还行，最新的方便 API 齐全。 |
| 35 wangtian2020 2023-11-07 17:12:48 +08:00 @DOLLOR 2023 年了， node-sass 早就一脚踹出依赖了 https://www.npmjs.com/package/node-sass dart-sass 直接平替 https://www.npmjs.com/package/sass |
Select Language