如何排除不安全的 package.json 临时依赖项？答案

【问题标题】：How do I exclude insecure package.json transient dependencies?如何排除不安全的 package.json 临时依赖项？
【发布时间】：2019-05-24 18:47:26
【问题描述】：

我有一个package.json 那个gives a load of security warnings。查看第一个关键项目，我看到它的open@0.0.5 已经五年没有更新了。查看npm ll 它包含在npm@6.5.0 中，我使用的是大约两周前更新的最新版本。

我想删除不安全的依赖项。在 Java 世界中，maven package manager 允许您排除某些传递依赖项。理想情况下，使用npm 或其他节点包管理器，我应该能够排除存在漏洞的依赖项。然后我可以重新测试我的应用程序是否正常工作，并且看不到任何安全错误。有没有办法从我的 package.json 中快速排除任何有安全漏洞的东西？如果没有办法做到这一点，可以采取哪些方法来确保我的应用程序不使用不安全的包？

更新：尽管在 package.json 中指定了 "npm": "^6.5.0"，但我正在使用较旧的 npm 构建它，该 npm 解决了上述关键问题。我用./node_modules/.bin/npm audit fix --force修复了所有问题

【问题讨论】：

标签： node.js npm package.json

【解决方案1】：

根据定义，您不能排除您正在使用的依赖项所依赖的包。换句话说，如果您需要包A，并且包A 声称它依赖于包B，那么删除包B 将导致A 要么完全停止工作，要么开始出现异常行为。

不幸的是，这确实发生了，您的选择包括：

忽略安全警告。
将包 A 替换为其他内容（在某些情况下适用，在其他情况下不适用）。
要求包A 的维护者升级他们所依赖的包B 的版本，可能自己打开一个拉取请求。

不过，在您的情况下，我不确定您的调查是否完成 - 我在 npm 的依赖项列表中没有看到 open。可能值得废弃你的 node_modules 并重新运行 npm install，然后再次检查以查看谁在使用 open。

【讨论】：

我已经更新了关于从旧的全局安装的 npm 获取该依赖项的问题
如果你在做 TDD，那么排除传递依赖似乎是一件有效的事情，因为如果没有依赖就无法工作，你就不会发布代码。让人们选择排除他们可以确认他们不使用的东西似乎是避免臃肿和安全问题的重要功能。这可能就是它存在于其他生态系统中的原因。
我想它归结为哲学比什么都重要。如果包 A 依赖于许多它实际上并不需要的包，那么这是一个设计不佳的包（它可以使用对等依赖项，并根据它们的存在提供可选功能）。排除您使用的包的依赖项是对包的内部实现做出不可执行的声明，因为显然作者认为它应该存在，并且可能会发布依赖它的次要版本更新。
作为 gothinkster/react-redux-realworld-example-app 分支的代码库看起来包含 2126 个依赖项。所有这些都被应用程序逻辑使用似乎有点难以置信。也许设计不佳的包是常态。
我不想说这是规范，但 npm js 中的当前范式倾向于小型集中包，并且“框架”（如 babel、eslint、express、react 之类的包）可以轻松拥有 300 多个包的树。

【解决方案2】：

此特定警告针对您的锁定文件，可以通过删除 yarn.lock 或 package-lock.json 并重新安装依赖项轻松修复。

【讨论】：

【解决方案3】：

Tarn 包管理器具有功能解决方案，您可以通过该功能将固定库设置为不安全的第三方。

看 How do I override nested dependencies with `yarn`?

NPM 也有类似的东西。

【讨论】：