想要阅读更多优质文章，请戳GitHub博客，一年数百篇优质文章等着你！简介如果您已将节点包管理器(npm)更新到版本5.x.x，一切似乎都运行良好。等等，这是什么？使用npm初始化项目会自动创建一个新文件package-lock.json。如果你打开它，它看起来有点像package.json的依赖关系，但更冗长。我们决定忽略它并继续开发该项目。最终，我们有时会遇到依赖项问题、未找到问题或安装了错误的版本。大多数人最终会删除package-lock.json并运行“npminstall”。那么，为什么它在那里？它应该做什么？它实际上做了什么？总结如果你使用npm版本^5.x.x，默认情况下会自动生成package-lock.json并且你应该使用package-lock来确保一致的安装和兼容的依赖你应该将package-lock提交到源代码控制从npm开始^5.1.xpackage.json能够胜过package-lock.json，因此您的头痛更少，你必须了解语义版本控制（semver）。这就是npm背后的天才之处，也是让它更加成功的原因。您可以在此处阅读有关npm如何使用它的更多信息。简而言之，如果您正在构建一个与其他应用程序交互的应用程序，您应该传达您所做的更改将如何影响第三方与您的应用程序交互的能力。这是通过语义版本控制完成的，版本由三部分组成：X、Y、Z，分别是主要版本、次要版本和补丁版本。例如：1.2.3，主要版本1，次要版本2，补丁3。补丁中的更改表示不破坏任何内容的错误修复。次要版本更改代表不会破坏任何内容的新功能。主要版本更改表示破坏兼容性的重大更改。如果用户对主要版本更改不满意，内容将无法正常工作。管理包npm的存在是为了让管理包变得容易。您的项目可能有数百个依赖项，每个依赖项都有一百个。为了让你的注意力远离依赖地狱，通过npm管理，用一些简单的命令，你可以安装和管理这些依赖。您几乎不必考虑它们。当您使用npm安装包（并保存它）时，一个条目将添加到package.json中，其中包含包名称和它应该使用的semver。默认情况下，npm安装最新版本并预先插入版本号，例如“^1.2.12”，表示至少要使用1.2.12版本，但是任何高于1.2.12的版本都可以，只要有相同的主版本，因为次版本号和补丁号只代表bugfixes和non-breaking添加，您可以安全地使用同一主要版本的任何更高版本。要阅读有关semver通配符的更多信息，请参阅此处。在package.json中为共享项目定义此类依赖项的真正好处是，任何有权访问package.json的人都可以创建一个依赖项文件夹，其中包含运行应用程序所需的模块，但让我们看看事情可能出错的具体方式。假设我们创建一个将使用express的新项目。运行npminit后，我??们安装express：npminstallexpress-save。在编写代码时，最新版本是4.15.4，因此在我的package.json中添加了“express”：“^4.15.4”作为依赖项，并且我的计算机安装了确切的版本。现在也许明天，express的维护者将发布一个错误修复，因此最新版本变为4.15.5。然后，如果有人想为我的项目做贡献，他们会克隆它，然后运行??`npminstall。'因为4.15.5是更新版本，主版本相同，请安装。我们都有快速安装，但我们有不同的版本。从理论上讲，它们应该仍然兼容，但也许错误修复会影响我们正在使用的功能，并且我们的应用程序在使用Express版本4.15.4和4.15.5运行时会产生不同的结果。Package-lock目的package-lock.json的目的是避免上述情况，即从同一个package.json安装模块会导致两个不同的安装。package-lock.json是在npm版本5.x.x中添加的，因此如果您使用的是主要版本5或更高版本，除非您禁用它，否则它会自动生成。内容结构package-lock是package.json中列出的每个依赖项的大列表，应该安装的具体版本，模块的位置（URI），验证模块完整性的哈希，包列表它需要，以及项目的依赖项列表。让我们看看express的列表是什么："express":{"version":"4.15.4","resolved":"https://registry.npmjs.org/express/-/express-4.15.4.tgz","完整性":"sha1-Ay4iU0ic+PzgJma+yj0R7XotrtE=","requires":{"accepts":"1.3.3","array-flatten":"1.1.1","content-disposition":“0.5.2”，“内容类型”：“1.0.2”，“cookie”：“0.3.1”，“cookie签名”：“1.0.6”，“调试”：“2.6.8”，“depd”：“1.1.1”，“encodeurl”：“1.0.1”，“escape-html”：“1.0.3”，“etag”：“1.8.0”，“finalhandler”：“1.0.4","fresh":"0.5.0","merge-descriptors":"1.0.1","methods":"1.1.2","on-finished":"2.3.0","parseurl":“1.3.1”，“正则表达式路径”：“0.1.7”，“代理地址”：“1.1.5”，“qs”：“6.5.0”，“范围解析器”：“1.2.0","send":"0.15.4","serve-static":"1.12.4","setprototypeof":"1.0.3","statuses":"1.3.1","type-is":"1.6.15","utils-merge":"1.0.0","vary":"1.1.1"}}，可以在requires部分列出的各个包中找到后等效项npm(^5.x.x.x)，npm使用package-lock.json而不是package.json来解析和安装模块。因为package-lock为每个模块及其每个依赖项指定了版本、位置和完整性哈希，所以它每次都会创建相同的安装。不管你使用什么设备，或者将来安装它，它每次都应该给你相同的结果，这是非常有用的。争议因此，如果引用package-lock是为了解决一个常见问题，为什么它的热门搜索结果（除了npm文档之外）都是关于禁用它或质疑它所扮演的角色？在npm5.x.x之前，package.json是项目的真实来源，npm用户喜欢这种模型并且非常习惯于维护他们的包文件。但是，当package-lock首次引入时，它的表现与许多人的预期相反。给定一个预先存在的包和包锁，对package.json的更改（许多用户认为这是真实的来源）没有同步到包锁中。示例：包A，版本1.0.0在package.json和package.lock.json中。在package.json中，A被手动编辑为1.1.0版本。如果相信package.json是真实来源的用户运行npminstall，他们将期望安装1.1.0版本。但是，安装了1.0.0版后，他们希望安装1.0.0版，即使package.json中列出了v1.1.0。示例：一个模块不存在于package-lock.json中，但它存在于package.json中，作为将package.json视为真实来源的用户，我希望能够安装我的模块。但是，由于package-lock.json中不存在该模块，因此未安装该模块，我的代码因找不到该模块而失败。大多数时候，因为我们无法弄清楚为什么我们的依赖项没有正确安装，所以要么删除package-lock.json并重新安装，要么禁用package-lock.json完全解决问题。这种期望与实际行为之间的冲突导致了npm存储库中一个非常有趣的问题线索。有些人认为package.json应该是真实的来源，有些人认为既然package-lock是npm用来创建安装的东西，它应该被认为是真实的来源。这一争议的解决方案在于PR#17508。如果package.json已更新，则Npm维护者添加了一项更改，导致package.json覆盖包锁定。现在，在上述两种情况下，用户期望安装的软件包都已正确安装。此更改作为npmv5.1.0的一部分发布，于2017年7月5日上线。您的点赞是我继续分享好东西的动力，欢迎点赞！欢迎加入前端大家庭，前端大家庭会经常分享一些技术资源。
