升级老项目的包依赖

背景介绍

项目使用 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. 比如 [email protected] 是要求 nodev12，@[email protected] 要求 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 企图替换，会造成命令循环