推荐关注
› Meteor
› JSLint - a JavaScript code quality tool
› jsFiddle
› D3.js
› WebStorm
推荐书目
› JavaScript 权威指南第 5 版
› Closure: The Definitive Guide
› Closure: The Definitive Guide
大家怎么解决 node_modules 里面， 引用的第三方包的深度依赖需要升级，但是直接依赖“不 需要/想 升级”的情况？
yazoox · 2021-04-07 11:24:50 +08:00 · 1172 次点击这是一个创建于 1309 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如，现在需要升级 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/
第 1 条附言 · 2021-04-07 15:04:42 +08:00
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.
这个功能太高级了，考虑一下要不要做进去......
 |
1
murmur 2021-04-07 11:29:24 +08:00
我们的 node_modules 改动过的部分直接传了 git，整个 node_modules 有完整的 zip 打包，如果谁依赖出问题全包替换就行
当然原则是，除非必须，坚决不升级 |
 |
2
whypool 2021-04-07 11:39:25 +08:00 via Android
锁版本，不升级
|
 |
3
DOLLOR 2021-04-07 11:43:48 +08:00
把 node_modules.7z 提交到 git 上。
|
 |
4
muzuiget 2021-04-07 14:16:52 +08:00
要么全升，要么全不升。workaround 就是 workaround，迟早要解决的，搞得那么复杂反把自己绕晕。
|
 |
5
xrr2016 2021-04-07 18:02:00 +08:00
指定插件的 peerDependencies，让插件使用项目的依赖包，不过这样需要自己去 fork 一份
|
 |
6
Mutoo 2021-04-07 18:50:59 +08:00
第三方包依赖不同版本的话，会在它们自己的目录创建 node_modules 下载对应的版本，并不会跟你的直接依赖冲突。它们目录下的同名包有更高的优先级被 import 。这个是 npm 一开始设计出来就解决的问题。
|
 |
7
libook 2021-04-08 12:06:01 +08:00
可以改 package-lock.json 来临时升级，部署的时候用 npm ci 而不是 npm install，npm audit fix 和 GitHub 的漏洞扫描应该都是用的这种处理方案。
然后轮子长期不维护或者明确表示不愿意升级依赖，就自己 fork 一份，然后改依赖，提 PR，主项目合并 PR 之前在 package.json 里用自己 fork 的版本。 |
 |
8
stabc 2021-04-08 22:39:07 +08:00
因为酸酸乳
|
Select Language