package-lock.json文件，带有“可选”的软件包：true

Question

我的一位同事的PR包含package-lock.json更新，其中添加了"optional": true：

 "minimist": {
   "version": "0.0.8",
   "bundled": true,
-  "dev": true
+  "dev": true,
+  "optional": true
 },
 "minipass": {

即使在四处搜寻后，我也不知道这意味着什么。有人可以解释一下吗？

Answer 1

如果为true，则此依赖项仅是顶层模块的可选依赖项，或者是一个传递性依赖项。对于既是顶层的可选依赖关系又是顶层的非可选依赖关系的传递性依赖关系的依赖关系，则为false。

合并此更改是安全的。

您看到此更改的原因很可能是因为npm稍微改变了版本6.6中package-lock.json的结构。您的伴侣基本上在npm install先前由npm 6.5-生成的package-lock.json上以npm 6.6+运行。

通过确保团队中的每个人都使用最新版本的，您应该能够避免此类问题npm。

Answer 2

从依赖项中删除软件包后，其依赖项将标记"optional": true为package-lock.json。

通常安全的方法是用手或用手提袋取出此类包装

$ rm -rf package-lock.json node_modules/
$ npm install

但是，这不是100％安全的，因为某些软件包将更新为较新的版本。

参考您的：*“不是 100% 安全，因为某些软件包将更新到较新的版本”*。拥有包管理器的全部意义在于能够克隆、安装并拥有一个可用的系统。全面采用相同的工作系统。如果您的项目依赖于某些具有旧版本的软件包，仅仅因为最近没有运行“npm i”，那么您就做错了。 (6认同)
@tao 考虑到上游软件包发布错误的频率以及其中一些软件包忽视 SemVer，我同意运行“npm i”并不是 100% 安全的观点。 (3认同)
CI 方法中没有任何地方假设您应该运行“npm i”。事实上，npm 维护者甚至为我们提供了一个实际上安全的替代方案：“npm ci”，正如文档中提到的，它是为 CI 环境而设计的。现在，您可以质疑这是否理想，但这是您必须与 NPM 团队本身讨论的事情。 (3认同)
假设即使是“不受您控制”的库的补丁版本也始终是 100% 安全且兼容，这种想法很天真，最终会破坏您的网站。上游开发者也是人，他们也会犯错误。每一次升级，无论多么微小，都必须经过测试。盲目运行“npm i”，除非您已将所有依赖项固定到特定版本，否则永远不是一个好主意。希望您在 CI 管道中进行测试，以捕获至少在投入生产之前可能出现的任何问题。 (2认同)

Answer 3

原因之一是：

某些 npm 包可能需要依赖包（例如 minimist）才能在不同的操作系统中工作。NPM 在 npm install 上将此软件包标记为可选，如果有的话，它不是必需的，具体取决于您使用的操作系统。

请检查以下问题：

开放问题：package-lock.json 和可选包：https://github.com/npm/npm/issues/17722

希望能帮助到你。