Javascript 是否应该将 package-lock.json 文件添加到 .gitignore 中？

Should the package-lock.json file be added to .gitignore?

提问by Francisco Maria Calisto

To lock the versions of dependencies that are installed over a project, the command npm installcreates a file called package-lock.json. This was made since Node.js v8.0.0and npm v5.0.0, as several of you might know.

要锁定在项目上安装的依赖项的版本，该命令npm install会创建一个名为package-lock.json. 这是自Node.js v8.0.0和npm v5.0.0以来制作的，你们中的一些人可能知道。

Despite of Node.jsand npmrecommendations about committing this file, several concerns regarding when you should avoid to do it, are also an option. Typically we commit in our projects, nevertheless, it is a peculiar question.

尽管Node.js和npm建议提交此文件，但关于何时应该避免这样做的几个问题也是一种选择。通常我们会在我们的项目中提交，然而，这是一个特殊的问题。

While we should commit the package-lock.jsonfile by default, we have a specific case we should not. For instance, if we want to test the latest version of our project dependencies, it can be an option to add package-lock.jsoninto .gitignore.

虽然package-lock.json默认情况下我们应该提交文件，但我们有一个不应该提交的特定情况。例如，如果我们想测试最新版本的项目依赖项，可以选择将其添加package-lock.json到.gitignore.

So, the questions are as follows:

所以，问题如下：

1. Should the package-lock.jsonfile be added to .gitignore?
2. Is there any particular situation that we MUSTor MUST NOTdo it?

1. 应该将package-lock.json文件添加到.gitignore?
2. 有什么特别的情况，我们必须或绝不能做呢？

回答by k0pernikus

No, the package-lock.jsonSHOULD NOTbe added to .gitignore. Instead, I strongly advise:

不，package-lock.json不应该添加到.gitignore. 相反，我强烈建议：

1. Add the package-lock.jsonyou to your version control repository
2. Use npm ciinstead of npm installwhen building your application both locally and in your deployment pipeline.
   (The cicommand is available since [email protected], if in doubt upgrade your npm via:
   npm install -g npm.)

1. 将package-lock.json您添加到您的版本控制存储库
2. npm cinpm install在本地和部署管道中构建应用程序时使用代替。
   （该ci命令自 [email protected] 起可用，如果有疑问，请通过以下方式升级您的 npm：。
   npm install -g npm）

---

---

One of the biggest downside of the npm installcommand is its unexpected behavior that it may mutate the package-lock.json, whereas npm cionly uses the version in the lockfile and produces an error if the package-lock.jsonand package.jsonare out of sync.

该npm install命令的最大缺点之一是它可能会改变 的意外行为package-lock.json，而npm ci仅使用锁定文件中的版本并在package-lock.json和package.json不同步时产生错误。

Also, npm cirequiresthe existence of a package-lock.jsonand would print an error if it wasn't there. There is a strong use-case for being able to trust that the project's dependencies resolve repeatably in a reliable way across different machines.

此外，npm ci需要 a的存在，package-lock.json如果不存在，则会打印错误。有一个强大的用例可以相信项目的依赖项在不同的机器上以可靠的方式可重复地解决。

Furthermore, npm cinukes the entire node_modulesfolder before adding the dependencies making sure you work with your actual dependencies instead of local changes while still being faster than a normal npm install.

此外，在添加依赖项之前npm ci核对整个node_modules文件夹，确保您使用实际的依赖项而不是本地更改，同时仍然比正常的npm install.

From a package-lock.jsonyou get exactly that: a known-to-work state.

从 apackage-lock.json你得到正是这样：一个已知的工作状态。

In the past, I had projects without package-lock.json/ npm-shrinkwrap.json/ yarn.lockfiles whose build would fail one day because a random dependency got a breaking update. (While a lot of libraries respect the semvar versioning guideline, you have no guarantee they won't break on a minor upgrade.)

在过去，我有项目的时候不用package-lock.json/ npm-shrinkwrap.json/yarn.lock文件，它们的构建将失败1天因为随机的依赖有一个破碎的更新。（虽然很多库都遵守 semvar 版本控制指南，但您不能保证它们不会在小升级时中断。）

Those issue are hard to resolve as you sometimes have to guess what the last working version was.

这些问题很难解决，因为您有时不得不猜测上一个工作版本是什么。

In regards to testing the latest dependencies for your project: This is what npm updateis for and I argue that it should be run by a developer, who also runs the test locally, who resolves issue if they may arise, and who then commits the changed package-lock.json. (If an upgrade fails, they can revert to the last working package-lock.json.)

关于测试项目的最新依赖项：这就是为什么npm update，我认为它应该由开发人员运行，开发人员也在本地运行测试，如果问题可能出现，谁解决，然后提交更改的package-lock.json. （如果升级失败，他们可以恢复到上次工作package-lock.json。）

Furthermore, I rarely upgrade all the dependencies at once (as that too might require further maintenance) but I rather cherry-pick the update I need (e.g. npm update {dependency}, or npm install {dependency}@2.1.3). Which is another reason why I would see it as a manual maintenance step.

此外，我很少一次升级所有依赖项（因为这也可能需要进一步维护），但我更愿意挑选我需要的更新（例如npm update {dependency}， 或npm install {dependency}@2.1.3）。这是我将其视为手动维护步骤的另一个原因。

If you really want to have it automated you could create a job for:

如果你真的想让它自动化，你可以创建一个工作：

• checkout repository
• run npm update
• run tests
  • if tests passes, then commit and push to repository
  • else fail and report issue to be manually resolved

• 结帐存储库
• 运行 npm 更新
• 运行测试
  • 如果测试通过，则提交并推送到存储库
  • 否则失败并报告问题需要手动解决

This is something I would see hosted on a CI server, e.g. Jenkins, and it should not be achieved through aforementioned reason through adding the file to the .gitignore.

这是我会看到托管在 CI 服务器上的东西，例如 Jenkins，它不应该通过上述原因通过将文件添加到.gitignore.

---

---

Or to quote npm doc:

或者引用 npm doc：

It is highly recommended you commit the generated package lock to source control: this will allow anyone else on your team, your deployments, your CI/continuous integration, and anyone else who runs npm install in your package source to get the exact same dependency tree that you were developing on. Additionally, the diffs from these changes are human-readable and will inform you of any changes npm has made to your node_modules, so you can notice if any transitive dependencies were updated, hoisted, etc.

强烈建议您将生成的包锁提交到源代码控制：这将允许您团队中的任何其他人、您的部署、您的 CI/持续集成以及在您的包源中运行 npm install 的任何其他人获得完全相同的依赖关系树你正在开发的。此外，这些更改的差异是人类可读的，并且会通知您 npm 对您的 node_modules 所做的任何更改，因此您可以注意到是否有任何传递依赖项被更新、提升等。

And in regards to the difference between npm civs npm install:

关于vs之间npm cinpm install的区别：

• The project must have an existing package-lock.json or npm-shrinkwrap.json.
• If dependencies in the package lock do not match those in package.json, npm ciwill exit with an error, instead of updating the package lock.
• npm cican only install entire projects at a time: individual dependencies cannot be added with this command.
• If a node_modulesis already present, it will be automatically removed before npm cibegins its install.
• It will never write to package.jsonor any of the package-locks: installs are essentially frozen.

• 该项目必须具有现有的 package-lock.json 或 npm-shrinkwrap.json。
• 如果包锁中的依赖项与 package.json 中的依赖项不匹配，npm ci则会出现错误退出，而不是更新包锁。
• npm ci一次只能安装整个项目：无法使用此命令添加单个依赖项。
• 如果 anode_modules已经存在，它将在npm ci开始安装之前自动删除。
• 它永远不会写入package.json或任何包锁：安装基本上是冻结的。