nodejs前端项目 如何显式指定某个依赖的版本 resolutions 字段 + npm-force-resolutions 插件 package-lock.json

总目录： 如何使用VSCode插件codesight扫描出前端项目的风险依赖包并借助 npm-force-resolutions 修复之？blackduck issue fix

问题描述

一个前端项目即将上线，在项目依赖风险扫描这一步出现了问题，需要修改一些依赖包（也包括深层依赖，即依赖的依赖）的版本，指定到系统认为安全的版本。

这类问题，如果是Java后端+Maven管理依赖的场景下，可以在pom.xml中配置dependencyManagement达到效果。
那么前端有没有拥有类似功能的配置？
有：package.json中的resolutions字段配置。

【解决方案】

对于直接依赖(node install xxx直接安装、并写入package.json中的依赖)，可以修改其版本号。

而对于那些间接依赖/深层依赖，需要在package.json中新增preinstall和resolutions。
preinstall中的命令会在你执行npm install之后，执行安装之前执行。注意其中的插件npm-force-resolutions
而那些需要限制版本号的依赖，你可以列在resolutions中。

{
  "name": "react-env",
  "scripts": {
    "preinstall": "npm install --package-lock-only --ignore-scripts && npx npm-force-resolutions",
    ...
  },
  "resolutions": {
    "tar": "6.1.13",
    "trim-newline": "4.0.2"
  },
  "dependencies": {
    "sass": "5.0.0",
    ...
  }
}

需要注意的是，本来resolutions对npm是无效的，只在使用yarn管理安装依赖时有用。
这里有用是因为插件npm-force-resolutions。

还要注意的是，npm + npm-force-resolutions 的组合，需要项目里有一个package-lock.json文件。
如果你项目里没有该文件，或者是与之功能相似的npm-shrinkwrap.json文件，都需要先把需要的文件生成出来。

代码库变动demo

git repo： https://gitee.com/wuyujin1997/react-env/tree/hotfix%2Ffix-blackduck-issue/

PR：https://gitee.com/wuyujin1997/react-env/pulls/1/files

参考

前端依赖的版本号语法

平时在命令行npm install react会直接安装该依赖的最新版本，等效于执行npm install react@latest。
安装命令之后会写到pacakge.json中，版本号一般不精确指定版本号。

按格式：主版本号.次版本号.修订版本号

^1.2.3 只限定主版本号，次版本号和修订版本号可升级。相当于1.x.x。
~1.2.3 主版本号+次版本号被限定，修订版本号可升级。相当于1.2.x。
1.2.3 完全指定主版本号、次版本号、修订版本号。就只表示1.2.3这一个版本。

当然，关于版本号的规则，还有更多，你可以看看：

yarn 可以在 package.json 中通过 resolutions 指定依赖的版本

https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/
Yarn支持指定版本的solutions，这样你就可以通过在package.json中编辑resolutions字段内容的方式，来自己指定某些依赖的版本了。

https://classic.yarnpkg.com/en/docs/package-json/

npm想要读取 package.json 中的 resolutions 需要一个配合另一个插件

https://www.npmjs.com/package/npm-force-resolutions
npm-force-resolutions 这个依赖包通过修改package-lock.json文件来强行限制那些传递依赖(依赖的依赖)的指定版本。
这个功能很像yarn的指定依赖解决方案(selective dependency resolutions)，但不需要迁移到yarn。

This packages modifies package-lock.json to force the installation of specific version of a transitive dependency (dependency of dependency), similar to yarn’s selective dependency resolutions, but without having to migrate to yarn.

package-lock.json 和 npm-shrinkwrap.json

package-lock.json 如何生成

你有一个node前端项目，有一个package.json，里面有dependencies、devDependencies等字段会列出所需依赖。
当你执行npm install成功后，会生成一个package-lock.json文件，这个文件里详细地列出了你所需依赖的层级、确切版本等。

npm-shrinkwrap.json 如何生成

你的项目里已经有package-lock.json文件了，这时执行npm shrinkwrap就会有以下两个效果：

• 自动删除package-lock.json
• 自动生成npm-shrinkwrap.json文件，其中内容来源于package-lock.json。至于两份数据是否一致这个我没注意，后面如果再有测试，会更新结论在这里。

package-lock.json 转为 npm-shrinkwrap.json

npm shrinkwrap

npm-shrinkwrap.json 转为 package-lock.json

两种方法

1. 重命名npm-shrinkwrap.json文件为package-lock.json。后面执行npm install的时候会自动去调整package-lock.json中的内容。
2. 删除npm-shrinkwrap.json文件，然后执行npm install。执行成功后相当于在此时此刻，根据package.json中列出的依赖下载到了哪些具体版本的依赖包，把这些依赖关系列出来写到了package-lock.json。

我选的是1。
比方说有一个三年前的项目，三年前执行npm install后生成了当时的package-lock.json，这个文件里列出的是当时具体的依赖层次和版本。
后来的npm-shrinkwrap.json里的数据来自于那个时候的pacakge-lock.json，或者说，来自那个可以使项目正常运行的依赖树(层次/版本)。

那我今天的修改，基于1，修改量会比较小。

如果选2，时过境迁，同一份package.json在不同时间、不同机器会下载到的依赖版本信息并不完全一致。
也许会导致一些依赖版本发生大的变化，而影响项目运行。

但推荐你两种都试试，失败就当是刷经验值。