这不是 ci / cleaninstall 的目的。 目前的行为是正确的。 您要使用的是npm shrinkwrap 。

我们添加了一个更新以避免删除 node_modules _folder_而不是它的_contents_ （如该帖子最初要求的那样）。 npm ci命令的目的是删除所有内容以从头开始。 如果您想保留旧的 node_modules，您需要的是npm i 。

感谢您的回复！ 抱歉这么晚才回复。 我看过npm shrinkwrap但这是否打算在我们的构建服务器上运行以进行持续集成？ 运行此命令时，它会将我的package-lock.json重命名为npm-shrinkwrap.json但是我应该在 CI 期间运行什么？ 只需npm install即可进行增量更新？ 或者我应该运行npm ci但这将再次删除所有包:-( 我正在寻找的是一个执行增量更新但将安装我们package-lock.json的命令的命令

@克劳迪亚兹； 我的理解是在 CI 期间运行npm install将更新package-lock.json ，这可能意味着几周后运行相同的构建会安装不同的包。 那不正确吗？

Ps 我认为npm ci是持续集成的缩写

如此处引用： https :

如果您在 Docker 容器内使用npm ci （这对于持续集成来说很常见）并且您在node_modules上有一个绑定安装，那么当前的行为是有问题的

它会导致以下错误：

webpack_1   | npm ERR! path /var/www/project/docker-config/webpack-dev-devmode/node_modules
webpack_1   | npm ERR! code EBUSY
webpack_1   | npm ERR! errno -16
webpack_1   | npm ERR! syscall rmdir
webpack_1   | npm ERR! EBUSY: resource busy or locked, rmdir '/var/www/project/docker-config/webpack-dev-devmode/node_modules'

然后导致中止 Docker 容器。

如果有--no-delete标志或者npm ci可以删除node_modules的 _contents_ 而不是目录本身，那就太好了。

ci = 全新安装

这是预期的。 为什么不使用带有锁文件的普通npm i ？

如果有一个 --no-delete 标志或者 npm ci 可以删除 node_modules 的内容而不是目录本身，那就太好了。

rm -rf node_modules/* && npm i

ci = 全新安装

这是预期的。 为什么不使用带有锁文件的普通 npm i 呢？

...因为： https :

此命令类似于 npm-install，不同之处在于它持续集成和部署——或任何您希望确保对依赖项进行全新安装的情况。 通过跳过某些面向用户的功能，它可以比常规的 npm 安装。 它也比常规安装更严格，可以帮助捕获由大多数 npm 用户增量安装的本地环境引起的

更快的安装和全新的方法使其成为我上面提到的 CI 环境的理想选择。

rm -rf node_modules/* && npm i

这就是我现在所做的，但请参阅上面使用npm ci的愿望

这似乎是合理的我提交一份RFC要求一个配置标志，使npm ci删除内容node_modules ，而不是目录本身。 这对我来说也是一个问题，因为我已经将 Dropbox 设置为选择性忽略node_modules目录，但是如果我删除它，该选择性设置就会消失，下次node_modules已创建，它会同步。

在我看来，提交一个 RFC 要求一个配置标志使npm ci删除node_modules的 _contents_ 而不是目录本身似乎是合理的。 这对我来说也是一个问题，因为我已经将 Dropbox 设置为选择性忽略node_modules目录，但是如果我删除它，该选择性设置就会消失，下次node_modules已创建，它会同步。

这不是另一个问题所描述的，允许 npm 创建文件以忽略目录（对于 OSX 聚光灯和其他人）？ 我认为还有其他人需要此功能。

ci = 全新安装

这是预期的。 为什么不使用带有锁文件的普通npm i ？

npm i会很棒，但前提是它不会更改锁定文件。 我已经看到在npm i期间更新了 package-lock.json 还是不应该发生这种情况？

我支持这个功能。 如前所述， npm i修改了 package-lock.json。 旗帜将是理想的解决方案。

同样，旗帜会很棒

我支持这个功能。 如前所述， npm i修改了 package-lock.json。 旗帜将是理想的解决方案。

那么为什么不为npm i添加一个标志呢？ 因为在我看来，这对ci = clean install没有多大意义。

“全新安装”的哪一部分与保持父node_modules/目录完整不兼容（同时对实际内容进行全新安装）？

我意识到在这种情况下 CI 不代表持续集成； 但是干净安装在持续集成环境中通常非常有用，正如文档所明确说明的那样。

此命令类似于 npm-install，不同之处在于它旨在用于自动化环境，例如测试平台、持续集成和部署 - 或任何您希望确保对依赖项进行全新安装的情况。 通过跳过某些面向用户的功能，它可以比常规 npm 安装快得多。 它也比常规安装更严格，可以帮助捕获由大多数 npm 用户增量安装的本地环境引起的错误或不一致。

npm ci专门用于自动化环境，很多时候这意味着基于 Docker 的设置。

删除node_module/目录的行为在基于 Docker 的设置中很麻烦，原因在此线程中提到。

因此，我们要求提供一个选项，使该命令对其预期目的和环境有用。

我支持这个功能。 如前所述， npm i修改了 package-lock.json。 旗帜将是理想的解决方案。

那么为什么不为npm i添加一个标志呢？ 因为在我看来，这对ci = clean install没有多大意义。

我不得不问这个问题是npm install和npm ci之间的任何其他区别，如果没有，那么为什么npm install中没有这两个选项可用，也许ci需要成为一些别名，如npm install --no-update-package-lock --clean-node-modules

删除node_module/目录的行为在基于 Docker 的设置中很麻烦，原因在此线程中提到。

在我看来，这应该只在构建图像时发生一次。 之后npm i应该在开发过程中使用。

也许ci需要变成像npm install --no-update-package-lock --clean-node-modules这样的别名

就我个人而言，这对我来说更有意义，普通npm i命令的附加标志。

我对此无动于衷，老实说，有太多的 n00b 与 js 土地有一个具体的论点，即它必须是ci ，我所知道的是它不应该更新package-lock.json和不应该删除node_modules

npm ci不更新锁文件，它从锁文件安装。 这是为了进行全新安装而引入的，因为之前建议人们rm -rf node_modules并再次运行npm i 。 而且 afaik 人们希望它不会更改锁定文件，而是从中安装。

于是npm ci诞生了。 它还会跳过一些内容，例如已安装的软件包列表和树以及其他一些内容。

见https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

它涵盖了一个特定的用例。

对于其他用例，我们应该向npm i添加新标志，我们还可以使用它来模拟npm ci ，这是一个比npm ci标志更灵活和更好的解决方案，后者仍应仅涵盖目前的用例恕我直言。 用户在这里要求的有点类似于yarn install --frozen-lockfile或yarn --frozen-lockfile 。

否则标志分布在npm ci 、 npm i等上，这使得它有点困难（文档，代码，...）。 至少这是我的想法。 让我们把它放在npm i t 有更强大和灵活的方式来配置它的行为。

对于其他用例，我们应该向 npm iwith 添加新标志，我们也可以模拟 npm ci，这是比 npm ci 的标志更灵活和更好的解决方案，后者仍应仅涵盖当前用例恕我直言。 用户在这里要求的有点类似于 yarn install --frozen-lockfile 或 yarn --frozen-lockfile。

如果将该功能添加到npm i我会非常高兴。 我应该更新原始帖子吗？

npm ci不更新锁文件，它从锁文件安装。 这是为了进行全新安装而引入的，因为之前建议人们rm -rf node_modules并再次运行npm i 。 而且 afaik 人们希望它不会更改锁定文件，而是从中安装。

于是npm ci诞生了。 它还会跳过一些内容，例如已安装的软件包列表和树以及其他一些内容。

见https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

它涵盖了一个特定的用例。

对于其他用例，我们应该向npm i添加新标志，我们还可以使用它来模拟npm ci ，这是一个比npm ci标志更灵活和更好的解决方案，后者仍应仅涵盖目前的用例恕我直言。 用户在这里要求的有点类似于yarn install --frozen-lockfile或yarn --frozen-lockfile 。

rm -rf node_modules/*不符合“清洁”的条件？ 这里要求的功能与 npm ci 中的功能非常相似。 在我看来，向 npm ci 添加一个标志更有意义，因此它使用rm -rf node_modules/*而不是rm -rf node_modules而不是将 npm ci 的整个行为导入到 npm i 中。

顺便说一句，这个问题应该得到更多关注，维护者应该对此发表意见和计划，使用 docker 基本上总是用于 CI（持续集成），这是 npm ci 的主要用例之一！

请为此更改打开 RFC，而不是此 repo 中的问题。

为了避免混淆，我将这个问题重命名为“在 npm CI 中为空而不是删除 node_modules 目录”

我对这个问题的意图是永远不会删除node_modules文件夹或仅删除它的内容。 始终保留node_modules的内容，但要确保它是最新的并与package-lock.json同步。 因此，遵循package-lock.json的增量更新。

也许我错了，但我觉得这里有两个问题。 也许有人可以开始另一个问题或关于仅删除 node_modules 内容而不是完全删除文件夹的 RFC？ 或者我错过了什么？

@Zenuka npm CI 快速且存在的全部原因是因为它忽略了现有的 node_modules 目录，因此不太可能改变。

在我们的用例中，我认为检查nodes_modules文件夹是否是最新的会更快。 如果不是，只更新应该更新的包（就像npm i那样）我有一些专用的 VM 作为构建代理运行，因此运行构建并保留nodes_modules文件夹及其所有内容应该比删除所有内容并重新安装更快。 我们运行我们的构建和测试代码更改比对package.json或package-lock.json更改要多得多。

在我们的用例中，我认为检查nodes_modules文件夹是否是最新的会更快。

嗯，这（包树的计算）是最耗时的。 这个检查会使npm ci真的很慢。

运行构建并保留nodes_modules文件夹及其所有内容应该比删除所有内容并重新安装更快。

可能不是，这就是为什么引入npm ci的原因，它跳过了npm i作用（检查包树）。

@Zenuka npm install已经是做你想做的最快的方式。 npm ci只有一个目的：通过删除 node_modules 来加快速度，这样它就不必计算差异。

可能不是，这就是为什么引入 npm ci 跳过 npm i 所做的（检查包树）。

我只在我的机器上测试过这个（这当然不是一个好的衡量标准）但是在最新的node_modules文件夹上运行npm install在 10 秒内完成。 运行npm ci需要几分钟。 你会期待不同的结果吗？

我很喜欢你的建议，即使用npm install添加一个标志来冻结锁定文件。

即使在 Windows 上，验证package-lock.json是否实际存在也非常快。 请参阅https://github.com/fuzzykiller/verify-node-modules。

验证node_modules中没有其他内容肯定需要更长的时间，但可能仍然不到一秒钟。

在此基础上，可以轻松创建npm ci的增量版本。 毕竟，树已经计算并保存到package-lock.json 。

此外，基本上npm ci存在的唯一原因是安装package-lock.json 。 没有像npm install那样潜入惊喜升级。

只是我的 2 美分，我个人将我们的基础设施切换到npm ci因为我也厌倦了部署旧标签npm i不会坚持锁定文件......所以如果它认真在npm ci级别添加标志是一个大问题（我得到了..它的clean install做它告诉我的事情）然后npm i REALLLLLYY 需要这个标志。 但我记得研究过这个，并且在npm i上也有一个问题线程，它已经超过 2 年了（并且仍然开放），npm 团队建议人们使用npm ci大声笑......这个这就是为什么人们过去放弃 npm 而只是去使用纱线的原因。

再次只是另一个开发人员的观点

我投票赞成增加保留模块的可能性 :heavy_plus_sign: 。

+1 在这里 - 正如@phyzical和@fuzzykiller所说，在npm install和npm ci之间没有“甜蜜点”可以保持 node_modules，但仍然尊重package-lock.json并运行得更快。
尽可能快地运行 - 从 node_modules 中已经存在的 package-lock 中查找依赖项，然后安装其他所有缺少的东西......不升级，不删除。

就我个人而言，我不在乎它是哪一个（ install或ci ）会有这个，但所有这些听起来都像npm install应该只对所有东西都有标志，而npm ci不需要是单独的命令。

这有点令人沮丧，因为npm ci最初被吹捧为解决此问题引发的同一问题的

许多人想要npm install的原始行为是查看package-lock.json而不是package.json 。 我们希望在npm install上有一个标志来开启这种行为。 我们得到的是npm ci ，因为：

package.json 描述了项目所需的依赖项。 如果当前锁文件不能满足这些，锁文件必须让步。 锁定文件的目的是在不同的机器上创建可重复的安装，而不是过时的 package.json。

如此精细。 npm install不是该选项的正确位置， npm ci是。 除了npm ci添加了其他行为（清除node_modules文件夹），使其无法成为原始问题的有用解决方案。 现在npm ci上不能有标志的原因是：

ci = 全新安装

这是预期的。 为什么不使用带有锁文件的普通 npm i 呢？

哪个……很好。 我真的不在乎在哪里添加标志。 我对界面背后的基本哲学没有任何兴趣。 但是可以在某个地方添加标志吗？

哎呀，即使人们想要一个完全独立的第三个命令，我也不会提出异议，我不在乎。 我唯一关心的是，在关于尊重package-lock.json正常安装的讨论开始 3 年后，仍然无法获得我们最初要求的行为。

在我的工作场所，我们看到了软件包的小错误和错误修复版本更新。 我们真的只想在有目的的软件包升级期间寻找这些错误，我们不希望我们的开发环境使用与生产环境不同的软件包版本。 那里的一致性非常重要。 无论任何人想称呼它或任何人想把它放在任何地方，我们都希望有一种快速的方法从锁文件中获取包，这也不需要我们每次都为已安装的模块进行node-gyp构建运行命令。

这就是我希望它在完美世界中工作的方式：

• npm install - 与今天相同的行为
• npm install --from-lockfile - 从锁文件安装（就像ci那样）
• npm install --clean - 与npm install相同的行为，但删除node_modules内容
• npm ci - npm install --from-lockfile --clean的别名

@jdussouillez这正是应该发生的事情。 说得好！ 我很想看到这个解决方案到位。

遇到这个问题总是令人沮丧，我们必须在 CI 管道的速度和一致性之间做出决定。 仅在过去的 2 个月里，我就因为不同的原因遇到过 3 到 4 次。

此功能非常适合 Azure Pipelines 和其他云架构。

https://docs.microsoft.com/en-us/azure/devops/pipelines/release/caching?view=azure-devops#tip

因为 npm ci 删除了 node_modules 文件夹以确保使用一致的、可重复的模块集，所以在调用 npm ci 时应该避免缓存 node_modules。

结束：正如@claudiahdz 所提到的，我们对这种行为进行了修复，其中npm ci不再删除node_nodules文件夹本身，而只删除它的内容（参考 https://github.com/npm /libcipm/blob/latest/CHANGELOG.md#407-2019-10-09）。 这是在 7 月 21 日以[email protected]发货的（参考 https://github.com/npm/cli/blob/v6/CHANGELOG.md#6147-2020-07-21）并且我们一直在维护npm@7的相同体验。

如果您对npm ci或任何其他命令有单独的问题，请使用我们的问题模板之一来提交错误： https :

旁注...

@jdussouillez感谢反馈； 在直接从锁定文件安装方面 - 您今天可以使用标志--package-lock-only （例如npm install --package-lock-only ）来做到这一点。 在将--clean标志添加到install ，我觉得这不会增加太多价值，但我可能是错的。 如果您对此有强烈的看法，我们很乐意让您在https://github.com/npm/rfcs 上提交 RFC

大约一年前@claudiahdz发表的评论似乎与确保npm ci行为是删除node_modules内容而不是文件夹本身有关。 这在将它安装到 docker 容器中时很方便（例如），但仍然不会改变最终结果 - npm ci将从头开始下载所有依赖项。

使用npm install --package-lock-only似乎与原始问题完全相反（如果我理解正确的话） - 它只会更新package-lock.json文件，并且不会下载任何依赖项。

我从原始问题中了解到，需要有一个选项来获取node_modules文件夹的当前状态和package-lock.json文件，并仅下载所需的包以获取node_modules版本匹配package-lock.json 。 因此，它比每次都下载所有内容要快得多，最终结果相同。

这不是npm install一直以来所做的吗？

这不是npm install一直以来所做的吗？

AFAIK -
npm install将根据package.json文件（忽略package-lock.json ）解析所有依赖，与node_modules文件夹中当前的内容进行比较，并下载需要下载以符合要求的依赖项。 它还将相应地更新package-lock.json 。

它绝对不会忽略锁文件——它只考虑现有的树，而npm ci不会。

你说得对，对不起。
我记错了，（也许这是过去的行为？）。 刚刚用一个简单的 dep 树做了一些测试，当package-lock.json文件存在时， npm i安装它指定的版本，并且不会改变任何东西。 这正是我正在寻找的行为，所以我很满意。 👍
我很抱歉在一个已关闭的问题上发帖。

我最初的要求确实是 ATGardner 所描述的：

我从最初的问题中了解到，需要有一个选项来获取node_modules文件夹的当前状态和package-lock.json文件，并仅下载所需的包以获取node_modules版本匹配package-lock.json 。 因此，它比每次都下载所有内容要快得多，最终结果相同。

我对npm install是它有时会更新package-lock.json文件。 今天早上我用一个我有一段时间没有更新的存储库再次测试了这个，并运行了git pull和npm i 。 这次实际上并没有更新任何版本，只是添加了一些依赖项和额外的包。

不幸的是，这是一个私人存储库，但也许其他人作为可复制的公共存储库？ 哪里有多个提交并在它们之间切换会导致npm install更新package-lock.json ？

我意识到在更新package.json时不提交package-lock.json可能会涉及一些用户错误，但我的同事知道他们也应该更新package-lock.json 。 我会调查这个。

我无法让npm i更改package-lock.json文件的简单示例。 但我会再试一次。

如果npm i总是最终下载package-lock.json指定的完全相同的版本，同时从当前的node_modules保留尽可能多的内容，为什么我需要运行npm ci ？ 在再次下载之前删除所有内容有什么好处？

见https://docs.npmjs.com/cli/v6/commands/npm-ci#description

我再次为这不是讨论的地方而道歉。 还有其他地方更可取吗？

我还是不明白。 如果状态node_modules运行后npm i完全匹配package-lock.json ，和状态node_modules运行后npm ci具有完全相同的最终结果 - 在几乎所有情况下，假设您正在构建的计算机已经在文件夹中具有一些/大多数依赖项， npm i会不会更快？ 它不会下载本地已经存在的内容，并匹配所需的版本。

为什么我宁愿从头开始删除和下载所有内容？

不， npm ci仍然更快，因为它不会再次检查 deptree，一些控制台输出没有完成。

为什么我宁愿从头开始删除和下载所有内容？

为了防止出现问题， ci用于特定环境，如部署。
我认为文档已经提到了差异。

通过跳过某些面向用户的功能，它可以比常规 npm 安装快得多。 它也比常规安装更严格，可以帮助捕获由大多数 npm 用户增量安装的本地环境引起的错误或不一致。

另见https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

npm ci仍然更快。

因此，当使用npm i ，读取当前node_modules并确定应该下载哪些包所花费的时间明显大于从 npm 中实际下载所有包所花费的时间服务器？ 我很想看到一个实际的实验来衡量它。

我也看不懂这一段——

npm ci bypasses a package’s package.json to install modules from a package’s lockfile. This ensures reproducible builds—you are getting exactly what you expect on every install.

我们是不是刚刚得出结论，运行npm i使用package-lock.json文件中的确切版本，并且运行后node_modules的状态与它会出现的状态相同在运行npm ci ？ 因此，构建将同样具有可重现性。

更新：

我做了以下测试 -
我创建了一个新的create-react-app项目。 完成初始化后，它有一个package.json有 7 个直接依赖项，还有一个package-lock.json包含 1982 个包。
在这种状态下（ node_modules包含所有依赖项） - 运行npm i需要

real    0m2.548s
user    0m2.659s
sys     0m0.182s

当我删除一个包文件夹（ node_modules/babel-eslint ），然后再次运行npm i时，它花了

real    0m3.295s
user    0m3.543s
sys     0m0.434s

重新下载丢失的依赖项

当我删除整个node_moduels文件夹并再次运行npm i时，

real    0m16.701s
user    0m19.251s
sys     0m10.379s

当我运行npm ci ，它花了

real    0m20.997s
user    0m23.844s
sys     0m14.857s

当我尝试删除单个包，甚至在调用之前手动删除整个node_modules文件夹时，这并没有太大区别。 这并不奇怪，因为npm ci node_modules无论如何都会删除

每次运行后，我运行diff -q -r node_modules_orig/ node_modules/以确保结果与原始依赖项相同。 一直都是。

所以总结一下 - 无论node_modules的当前状态如何，在我的机器上使用npm ci似乎需要大约 21 秒。 在最近克隆的项目（没有node_modules ）上使用npm i需要大约 18 秒，并在没有更改依赖项的项目上运行它（当前node_modules匹配所需的依赖项) 需要大约 3 秒。

那么什么时候使用npm ci更好？ 它看起来并不快（当然，这只是一个测试），并且最终结果与npm i ，因此后续构建将同样可靠。

当您需要 _exactly_ package-lock.json ， npm ci更可取。 npm i不保证它会完全安装package-lock.json 。 这是设计使然。 虽然package-lock.json是npm i的输入，但它也是输出。

我相信只有少数情况下npm i会安装不同的东西（从而修改package-lock.json ），比如可能被软删除的包版本。

回到npm ci首次引入时， npm i要么完全忽略package-lock.json要么至少在安装不同版本时更加主动。

无论哪种方式，这都无关紧要。 npm ci仅在node_modules文件夹尚不存在时才可以使用。 否则它会非常慢，尤其是在 Windows 上。 所以npm i只需要一个标志 _guarantees_ 它不会修改package-lock.json并安装package-lock.json 。

我认为进一步讨论原因和方式没有任何意义。 要么我们会得到它，要么我们不会。 按原样， npm ci很烂。

/更新：
这是一个存储库，其中运行npm i将更改package-lock.json ： https :

尽管这些更改本质上只是技术性的，但它们仍然是不可接受的。

只是快速重申：

• npm ci总是按设计删除node_modules的内容，这对于非生产构建是不可取的，因为它很慢。 但是，它使用在package-lock.json找到的包的精确版本，这在多种情况下都是可取的。

• npm install只是更新node_modules ，这是非常高效的，但是如果package.json版本号不同，它会在设计上忽略package-lock.json的内容，这是不适合多种情况。

• npm install --package-lock-only在文档中描述：

  --package-lock-only 参数只会更新 package-lock.json，而不是检查 node_modules 和下载依赖项。

  这对于上述任何场景似乎都没有用。

在过去的 3 年里，人们一直在问什么：

1. 将忽略package.json和 _only_ 尊重package-lock.json作为将安装哪些软件包的最终来源的命令（任何地方）。

2. 这不会删除node_modules的全部内容并从头开始重新下载所有内容。

据我从文档和本地测试中看到， npm install满足第 2 点，但不满足npm ci满足第 1 点，但不满足第 2 点。 npm install --package-lock-only不满足这些要求中。

我不完全确定为什么这个问题已被关闭，仍然无法获得所需的行为。

编辑：为了扩展@fuzzykiller的例子，不仅仅是package-lock.json得到更新。 那会很烦人，但它不会破坏我的任何构建。 但是，如果package.json在任何地方都列出了模糊依赖项，并且这些依赖项的错误修复版本被发布，那么当我在新机器上运行npm install时，它们会发生变化。 突然间我在两台机器之间安装了差异。 正是由于这种行为，我们在我的公司遇到了错误，不仅仅是package-lock.json需要再次检入 Git。

在这种情况下，最好有一个行为类似于npm ci ——它可以基于 _only_ 的内容进行可复制的安装package-lock.json 。 但是，删除node_modules文件夹的内容会在某些环境和情况下减慢构建速度，即使这是最终生产构建的适当行为。

任何地方都可能有一个标志来解决这个问题。 它可能是npm install --from-lockfile 。 它可能是npm ci --preserve-existing 。 但是现在似乎我们处于一个圈子里，任何要求将标志添加到npm install都会指向npm ci作为解决方案，而任何要求将标志添加到npm install人npm ci指向npm install作为解决方案。 此问题已关闭，指向npm install --package-lock-only ，但该标志几乎与人们要求的相反。 它不尊重package-lock.json作为权威来源，也不更新或安装node_modules文件夹中的任何依赖项:)

这个问题应该重新打开。