为什么“ npm install”会重写package-lock.json？

我最近才升级到npm @ 5。我现在有一个package-lock.json文件，其中包含package.json中的所有内容。我希望，当我运行npm install该依赖项版本时，将从锁定文件中提取依赖项版本，以确定应该在我的node_modules目录中安装什么。奇怪的是，它实际上最终修改并重写了package-lock.json文件。

例如，锁定文件已将打字稿指定为版本2.1.6。然后，在npm install命令之后，版本更改为2.4.1。这似乎破坏了锁定文件的全部目的。

我想念什么？如何让npm真正尊重我的锁定文件？

更新3：正如其他答案所指出的那样，npm cinpm 5.7.0中引入了该命令，作为在CI上下文中实现快速且可复制的构建的其他方法。有关更多信息，请参见文档和npm博客。

更新2：更新和澄清文档的问题是GitHub问题＃18103。

更新1：以下描述的行为已在npm 5.4.2中修复：GitHub问题＃17979中概述了当前预期的行为。

原始答案：的行为package-lock.json已在问题＃16866中在npm 5.1.0中更改。从5.1.0版开始，npm显然已观察到您所观察到的行为。

也就是说，只要在中找到依赖项的更新版本，package.json就可以覆盖。如果你想有效地定位您的依赖关系，您现在必须在没有前缀指定版本，例如，你需要将它们写成的，而不是或。然后，和的组合将生成可复制的构建。需要明确的是：仅凭它不再锁定根级别依赖项！package-lock.jsonpackage.json1.2.0~1.2.0^1.2.0package.jsonpackage-lock.jsonpackage-lock.json

不管这个设计决定是好的还是不可行的，在GitHub上的问题＃17979引起了持续的讨论。（在我看来，这是一个有问题的决定；至少这个名称lock不再适用。）

还有一点注意事项：对于不支持不可变软件包的注册表也有一个限制，例如当您直接从GitHub而不是npmjs.org提取软件包时。有关更多说明，请参见此软件包锁文档。

我发现将有一个新版本的npm 5.7.1和新命令npm ci，它将package-lock.json仅从

新的npm ci命令仅从锁定文件安装。如果您的package.json和锁定文件不同步，则它将报告错误。

它可以通过丢弃node_modules并从头开始重新创建来工作。

除了保证您只获得锁定文件中的内容外，如果不使用node_modules进行启动，它也比npm install快得多（2x-10x！）。

您可能会从名称中得知，我们希望它对持续集成环境大有裨益。我们还期望从git标签进行生产部署的人们会看到很大的收获。

使用新推出的

npm ci

npm ci承诺将为大型团队带来最大的利益。使开发人员能够“退出”软件包锁定功能可以促进大型团队之间更有效的协作，而完全安装锁定文件中内容的功能则可以每月节省数十甚至数百小时的开发人员时间，从而释放团队花更多的时间来建造和运输令人惊奇的东西。

引入npm ci更快，更可靠的构建

简短答案：

• npm install 仅当满足package.json的要求时，才对package-lock.json表示敬意。
• 如果不满足这些要求，则更新软件包并覆盖软件包锁定。
• 如果您宁愿使构建失败，也不愿在发生这种情况时重写package-lock，请使用npm ci。

这是一个可能说明问题的方案（已通过NPM 6.3.0验证）

您在package.json中声明一个依赖项，例如：

"depA": "^1.0.0"

然后，您将执行以下操作，npm install将生成一个package-lock.json：

"depA": "1.0.0"

几天后，发布了较新的次要版本“ depA”，例如“ 1.1.0”，则以下内容成立：

npm ci       # respects only package-lock.json and installs 1.0.0

npm install  # also, respects the package-lock version and keeps 1.0.0 installed 
             # (i.e. when package-lock.json exists, it overrules package.json)

接下来，您手动将package.json更新为：

"depA": "^1.1.0"

然后重新运行：

npm ci      # will try to honor package-lock which says 1.0.0
            # but that does not satisfy package.json requirement of "^1.1.0" 
            # so it would throw an error 

npm install # installs "1.1.0" (as required by the updated package.json)
            # also rewrites package-lock.json version to "1.1.0"
            # (i.e. when package.json is modified, it overrules the package-lock.json)

使用npm ci命令代替npm install。

“ ci”代表“持续集成”。

它将基于package-lock.json文件而不是宽松的package.json文件依赖项安装项目依赖项。

它会为您的队友生成相同的版本，并且速度也更快。

您可以在此博客文章中阅读有关此内容的更多信息：https : //blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

将来，您将能够使用--from-lock-file（或类似的）标志仅从进行安装，而package-lock.json无需对其进行修改。

这对于CI等可重现构建很重要的环境很有用。

请参阅https://github.com/npm/npm/issues/18286以跟踪功能。

看来此问题已在npm v5.4.2中修复

https://github.com/npm/npm/issues/17979

（向下滚动到线程中的最后一条注释）

更新资料

实际在5.6.0中已修复。5.4.2中存在一个跨平台错误，导致该问题仍然存在。

https://github.com/npm/npm/issues/18712

更新2

在这里看到我的答案：https : //stackoverflow.com/a/53680257/1611058

npm ci 是现在安装现有项目时应使用的命令。

您可能有类似以下内容：

"typescript":"~2.1.6"

您将package.json哪个npm更新为最新的次要版本，2.4.1

编辑：OP的问题

但这并不能解释为什么“ npm install”会更改锁定文件。锁定文件不是要创建可复制的版本吗？如果是这样，则无论semver值如何，都应仍使用相同的2.1.6版本。

回答：

这旨在锁定您的完整依赖关系树。假设typescript v2.4.1require widget ~v1.0.0。当您安装npm时，它会抓住widget v1.0.0。稍后在您的其他开发人员（或CI构建）上进行npm安装并获取，typescript v2.4.1但widget已更新为widget v1.0.1。现在，您的节点模块不同步。这是package-lock.json防止的。

或更笼统地说：

例如，考虑

套餐A：

{“名称”：“ A”，“版本”：“ 0.1.0”，“依赖关系”：{“ B”：“ <0.1.0”}}

套餐B：

{“ name”：“ B”，“ version”：“ 0.0.1”，“ dependencies”：{“ C”：“ <0.1.0”}}

和包C：

{“ name”：“ C”，“ version”：“ 0.0.1”}

如果这些是注册表中可用的A，B和C的唯一版本，则将安装普通的npm install A：

A@0.1.0-B@0.0.1-C@0.0.1

但是，如果发布了B@0.0.2，则将安装新的npm install A：

A@0.1.0-B@0.0.2-C@0.0.1假设新版本未修改B的依赖关系。当然，新版本的B可以包括新版本的C和任何数量的新依赖项。如果不希望发生此类更改，则A的作者可以指定对B@0.0.1的依赖。但是，如果A的作者和B的作者不是同一个人，那么当B完全没有变化时，A的作者就无法说他或她不想插入新发布的C版本。

OP问题2：所以让我看看我是否理解正确。您要说的是，锁定文件指定了二级依赖关系的版本，但是仍然依赖于package.json的模糊匹配来确定顶级依赖关系。准确吗？

答：不。package-lock锁定整个软件包树，包括中描述的根软件包package.json。如果typescript锁定在2.4.1中package-lock.json，则应保持这种状态，直到更改为止。并说明天typescript发布版本2.4.2。如果我签出您的分支并运行npm install，npm将遵守该锁文件并进行安装2.4.1。

更多内容package-lock.json：

对于npm修改node_modules树或package.json的任何操作，都会自动生成package-lock.json。它描述了生成的确切树，因此无论中间依赖项更新如何，后续安装都可以生成相同的树。

该文件旨在提交到源存储库中，并具有多种用途：

描述一个依赖关系树的单一表示，这样可以确保队友，部署和持续集成安装完全相同的依赖关系。

为用户提供一种便利，使其可以“时间旅行”到node_modules的先前状态，而不必提交目录本身。

为了通过可读的源代码控制差异更好地了解树的变化。

并允许npm跳过先前安装的软件包的重复元数据解析，从而优化安装过程。

https://docs.npmjs.com/files/package-lock.json

也许你应该使用这样的东西

npm ci

npm install 如果不想更改软件包的版本，请不要使用。

根据官方文件，都npm install和npm ci安装这些项目所需的依赖关系。

主要区别在于，npm install是否packge.json以参考安装软件包。对于npm ci，它会确实package-lock.json以参考的方式安装软件包，请确保每次都安装了确切的软件包。

在他们的github页面上有一个未解决的问题：https : //github.com/npm/npm/issues/18712

当开发人员使用不同的操作系统时，此问题最严重。

编辑：名称“锁”是一个棘手的人，其NPM试图赶上纱线。它不是一个锁定的文件。package.json是用户固定的文件，“安装”后将生成node_modules文件夹树，然后将该树写入package-lock.json。因此，您将看到相反的结果-依赖关系版本将package.json一如既往地被删除，package-lock.json应调用package-tree.json

（希望经过这么多次否决之后，我的回答才能更加清晰）

一个简单的答案：package.json像往常一样具有依赖关系，而这package-lock.json是“一个精确的，更重要的是可重现的node_modules树”（取自npm docs本身）。

至于棘手的名称，其NPM试图赶上Yarn。