升级老项目的包依赖
8333Frontendnpm2025-05-252025-06-01
背景介绍
项目使用 node v12, npm 管理,年代比较久远,现在要升级某一个工具包,但这个包并不是直接引用的,而是子包的依赖,但是这个项目要先于子包更新,所以需要单独更新这个工具包
npm 的 oversides 可以很容易实现这个需求,但是这个功能是 node v16 才有的,所以需要先升级到 v16 才能使用这个功能
node 版本升级就碰到亿点点了 node-gyp 的问题,而后放弃 npm,转化为使用 yarn 的 resolutions,然后也碰到了 node 版本兼容问题
Node-gyp 问题
- node-gyp 是用于编译 C/C++ 插件的工具。一些 node 包使用 C 来使用系统级别的 api 或者提升性能,所以这些包需要编译为二进制才能在 node 代码中引用,如果包作者没有提供和平台相应的二进制包,那 node-gyp 就会来做这件事
- 当切换 node 版本之后,一些插件需要重新编译,重新编译就需要提供环境, python 和 c ++ 工具链
node-gyp 版本问题
- npm 内部会打包一份 node-gpy 的复制版本,所以全局装 node-gyp, npm 也不会用到,但是有一些小手段可以更新 npm 内部的版本
- Updating-npm-bundled-node-gyp
找不到 python2 或 python3
- node-gyp 是对 google gyp 工具的封装,而 gyp((Generate Your Projects)) 是 python 写的,所以 python 是重新编译的必要条件
- python v3 是不兼容 v2 的,如果 gyp 说它找不到 v2,那就最好给它 v2
node 版本兼容
切换了管理工具,原来的 package.lock 对 yarn 实际上没有什么用,yarn 会生成 yarn.lock。大部分包的依赖的版本用
^
/~
来设置版本范围,本来项目初始化安装的时候这个包设的是^3.2, 可能当时最高版本就是3.2, 但是现在能找到最后一个版本 3.9. 比如 less@4.2 是要求 nodev12,@less@4.3 要求 nodev14 以上- 版本号格式:
4.17.21
, 具体版本号>=4.0.0 <5.0.0
, 字面意思,设定版本号范围^4.17.21
等于4.x.x
, 取最新以 4 开头的版本~4.17.21
, 等于4.17.x
, 取最接近于这个设置的版本4.*
, 等于4.x.x
,取最新以 4 开头的版本*
, 取最新的版本
- 包管理器决定依赖版本的逻辑的差异
- 版本号格式:
*
这个版本设置,比如某些包对commander``webpack-dev-server
依赖版本号设置是*
,这个符号本意是不在意包的版本,yarn 会去获取最新的包, 但是这就会导致 node 版本兼容问题solve:
- 刚开始可以尝试通过
yarn import
(废弃但可用) 或者synp
转换 package.json to yarn.lock.json - 可以通过在 solutions 中指定版本来解决
- 最后的最后,还可以通过
yarn install --ignore-engine
来忽略这个问题,如果因为项目部署原因不方便修改依赖安装脚本的,也可以将--ignore-engine
写在.yarnrc
文件中可以省略掉后续维护流水线的麻烦- 不要尝试将
install
写在scripts
企图替换,会造成命令循环
- 不要尝试将
- 刚开始可以尝试通过