大家怎么解决 node_modules 里面， 引用的第三方包的深度依赖需要升级，但是直接依赖“不 需要/想 升级”的情况？

[yazoox]

比如，现在需要升级 ssri 到 v8.0.1，因为报了 security issue 。webpack, storybook，都是依赖 ssri 的（好多层深度），只是依赖的版本比较低，比如 v6.0.1 或者 v8.0.0

可是，暂时不想把 webpack 或者 stroybook 升级到最新（比如，可能会有一堆新问题要解决，或者即使升级到最新版，他们引用的依赖，依然还是老的版本的情况，etc.）

npm 提供了一个方案，比如，package.json 里面，使用 resolutions，强制指定 ssri 到＾ 8.0.1 版本，是可以解决这个问题的。

不过，貌似该方法有一个“大坑”，就是，如果以后，我们添加了其它的包，比如 abc，它依赖 ssri v9.0.0，我们是不知道的。npm/yarn install 时，还是使用＾ 8.0.1 的版本。除非使用 abc 这个包的人，自己知道，这个包是依赖 ssri v9.0.0,然后去 resolutions 里面把指定的版本，改成 "ssri": "^v9.0.0"。但通常，一般人是不会去看自己引入的包，有哪些依赖的吧．．．．．.

（不知道我的理解对不对，如果不对，请指正）

大家有没有比较好的方法 /方案，解决类似的问题？

refer: https://classic.yarnpkg.com/en/docs/selective-version-resolutions/

yarn 本来有一个解决方案，可惜，没有实现
例如： https://github.com/yarnpkg/rfcs/blob/master/implemented/0000-selective-versions-resolutions.md#package-designation

Mapping version specifications This is a kind of simplified solution to the "out-of-scope scenario" presented in the Motivations section above (it maps versions but not dependency names).

It was proposed in this comment.

It is similar to the previous alternative but with a version specification in the package designation. This would take this form in the package.json:

  "devDependencies": {
    "@angular/cli": "1.0.3",
    "typescript": "2.2.2",
    "more dependencies..."
  },
  "resolutions": {
    "typescript@>=2.0.0 <2.3.0": "[email protected]"
  }

yarn would then replace matching version specifications with the user's one. For example a dependency normally resolved to [email protected] would be resolved in practice to [email protected].

This is too advanced and can be considered a possible extension of this RFC.

这个功能太高级了，考虑一下要不要做进去......

[murmur]

我们的 node_modules 改动过的部分直接传了 git，整个 node_modules 有完整的 zip 打包，如果谁依赖出问题全包替换就行

当然原则是，除非必须，坚决不升级

[whypool]

锁版本，不升级

[DOLLOR]

把 node_modules.7z 提交到 git 上。

[muzuiget]

要么全升，要么全不升。workaround 就是 workaround，迟早要解决的，搞得那么复杂反把自己绕晕。

[xrr2016]

指定插件的 peerDependencies，让插件使用项目的依赖包，不过这样需要自己去 fork 一份

[Mutoo]

第三方包依赖不同版本的话，会在它们自己的目录创建 node_modules 下载对应的版本，并不会跟你的直接依赖冲突。它们目录下的同名包有更高的优先级被 import 。这个是 npm 一开始设计出来就解决的问题。

[libook]

可以改 package-lock.json 来临时升级，部署的时候用 npm ci 而不是 npm install，npm audit fix 和 GitHub 的漏洞扫描应该都是用的这种处理方案。

然后轮子长期不维护或者明确表示不愿意升级依赖，就自己 fork 一份，然后改依赖，提 PR，主项目合并 PR 之前在 package.json 里用自己 fork 的版本。

[stabc]

因为酸酸乳