我知道package.json的主要优点，对此我表示同意。它不仅锁定了上次安装的下载版本，还锁定了uri ...，这在大多数情况下是必需的，以便尽可能地复制最相似的项目。
但是对我来说似乎很奇怪的是，dependency: ^1.0.0具有声明像package.json这样的依赖项的功能，这应该使npm在每次安装中都下载该软件包的最新版本和兼容版本
我正在实际需要这个项目。否则，每当我的依赖项发布补丁程序时，都将需要进行新的提交更新package-lock.json，仅更改版本，因此我的管道也可以覆盖package.json。
简而言之，似乎package-lock.json使用了一项功能... import pandas as pd
cols = ['col_1','col_2',...,'col_n']
df = pd.DataFrame.from_records(list_cols, columns=cols)
阻止了该功能。
我想念什么吗？
答案 0 :(得分：4)
package-lock.json的要点是准确地表示某个时间点上的树 ，以便克隆该项目的人完全你有一棵树。
如果要将该依赖项升级到较新的版本，只需使用npm update，然后提交更新的package-lock.json。您团队中的其他成员将获得该更新，这是获取最新消息的正常过程的一部分。
npmjs.com page on package locks中的更多内容。
让我们考虑一个场景，您和我在一个团队中，我们的项目使用nifty-lib，其中package.json表示"nifty-lib": "^0.4.0"，而我们不共享package-lock.json。也许我在该项目上的工作时间比您多了几个月，并且在安装它时获得了nifty-lib v0.4.0。但是，当您拿起它并安装时，得到了v0.4.1（一个错误修复程序更新，可悲的是，它引入了一个新错误）。在某个时候，您会注意到我们的项目中似乎有一个错误，但是我无法复制它。我们旋转了一段时间，试图弄清楚为什么它发生在您而不是我身上。最后，我们意识到这是因为实际上是他们在v0.4.1中引入的nifty-lib中的错误。希望我们能得到0.4.2或类似的东西（或者如果没有，则修复该错误并进行PR，同时在整个项目中回滚到0.4.0）。
如果我们一直在共享package-lock.json，那么我们就不会想知道为什么问题发生在您而不是我身上，因为您将拥有与{{1}我。作为我们正常周期的一部分，我们会定期进行nifty-lib，如果测试中出现新的错误，则从提交历史记录中知道这是由于依赖项中的错误所致。
现在，对于“我”和“您”，请阅读“开发”和“生产”。 ：-）
这就是npm update锁定版本的原因，但是package-lock.json可以让您说“此或更好”。 package.json使您的团队在版本上保持统一，但是您可以有意地使用package-lock.json进行更新，它会显示在提交历史记录中，以便您可以跟踪对它的回归。
答案 1 :(得分：2)
正如我在上面的评论中所提到的，简短的答案是它使update依赖项变得更容易。
但是，我想考虑这两个文件的另一种方式是： package.json 是人类读取的文件，而 package-lock.json 是文件计算机读取。
NPM是程序包/依赖项管理器。因此，在您的 package.json 文件中，写出“这些库才能正常工作。”作为功能，您可以列出依赖项的一系列版本。当您在特定程序包上运行npm update时，这会有所帮助。它会查看* package.json **中与之匹配并更新锁文件的最新版本。
package-lock.json 锁定文件非常有用，因为它详细描述了 node_modules / 文件夹的外观，以便在其他人安装您的库时可以准确地重新创建它。此外，由于该文件是自动生成的，因此您不必担心对其进行维护。
当然，所有这一切恰好是NPM（以及most package managers）如何处理这一问题的方式。也就是说，出于技术原因，我们没有一个文件可以描述运行更新时允许的版本范围，也没有一个冗长的锁文件部分来固定版本以允许可重新创建的依赖关系树。 >
基本上，这只是一个方便。您可以使用一个文件简要列出项目需要的依赖项。它易于阅读且易于更新。另一个文件（锁定文件）将自动生成，并确保每个npm install都为您提供与以前完全相同的 node_modules / 文件夹。