是否应该将package-lock.json文件添加到.gitignore? [英] Should the package-lock.json file be added to .gitignore?

问题描述

要锁定在项目上安装的依赖项的版本，命令npm install创建一个名为package-lock.json的文件.这是因为 Node.js v8.0.0 和

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

尽管 Node.js 和 npm 有关提交此文件的建议(有关何时应避免使用此文件的一些注意事项)的建议.通常，我们会提交项目，但这是一个特殊的问题.

Despite of Node.js and npm recommendations 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.

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

While we should commit the package-lock.json file 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.json into .gitignore.

因此，问题如下:

1. 是否应将package-lock.json文件添加到.gitignore?
2. 是否有我们必须或绝对不能这样做的特殊情况?

1. Should the package-lock.json file be added to .gitignore?
2. Is there any particular situation that we MUST or MUST NOT do it?

推荐答案

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

No, the package-lock.json SHOULD NOT be added to .gitignore. Instead, I strongly advise:

1. 将package-lock.json您添加到版本控制存储库中
2. 在本地和部署管道中构建应用程序时，请使用npm ci代替npm install .
   (ci命令自npm@5.7起可用，如有疑问，请通过以下方式升级您的npm:
   npm install -g npm.)

1. Add the package-lock.json you to your version control repository
2. Use npm ci instead of npm install when building your application both locally and in your deployment pipeline.
   (The ci command is available since npm@5.7, if in doubt upgrade your npm via:
   npm install -g npm.)

---

npm install命令最大的缺点之一是它的意外行为，它可能会使package-lock.json发生突变，而npm ci仅使用锁文件中的版本，并且如果package-lock.json和不同步.

---

One of the biggest downside of the npm install command is its unexpected behavior that it may mutate the package-lock.json, whereas npm ci only uses the version in the lockfile and produces an error if the package-lock.json and package.json are out of sync.

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

Also, npm ci requires the existence of a package-lock.json and 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在添加依赖项之前先对整个node_modules文件夹进行修改，以确保您使用实际的依赖项而不是本地更改，同时仍比正常的npm install快.

Furthermore, npm ci nukes the entire node_modules folder 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.

从package-lock.json您可以确切地知道:一个已知的工作状态.

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

过去，我有一些项目，这些项目没有package-lock.json/npm-shrinkwrap.json/yarn.lock文件，由于随机依赖项的最新更新，其构建将有一天失败. (尽管许多库都遵循semvar版本指南，但不能保证它们在进行较小的升级时不会中断.)

In the past, I had projects without package-lock.json / npm-shrinkwrap.json / yarn.lock files 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.)

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

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

关于测试项目的最新依赖关系:这是npm update的作用，我认为它应该由开发人员运行，该开发人员还要在本地运行测试，并解决可能出现的问题，以及然后谁提交更改的package-lock.json. (如果升级失败，他们可以还原到上一个工作的package-lock.json.)

In regards to testing the latest dependencies for your project: This is what npm update is 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 {dependency}或npm install {dependency}@2.1.3).这是我将其视为手动维护步骤的另一个原因.

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.

如果您真的想使其自动化，可以为以下项目创建工作:

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

• 结帐资料库
• 运行npm更新
• 运行测试
  • 如果测试通过，则提交并推送到存储库
  • 否则将失败并报告问题，以手动解决
  • 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

    这是托管在CI服务器上的内容，例如Jenkins，并且不应通过上述原因将文件添加到.gitignore来实现.

    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.

    或引用npm文档:

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

    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.

    关于 npm ci与npm install 之间的区别:

    And in regards to the difference between npm ci vs npm install:

    • 项目必须具有现有的package-lock.json或npm-shrinkwrap.json.
    • 如果程序包锁定中的依赖项与package.json中的依赖项不匹配，则npm ci将退出并显示错误，而不是进行更新 包裹锁.
    • npm ci一次只能安装整个项目:此命令无法添加单个依赖项.
    • 如果node_modules已经存在，则会在npm ci开始安装之前自动将其删除.
    • 它将永远不会写入package.json或任何软件包锁:安装实际上已冻结.

    • 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 ci will exit with an error, instead of updating the package lock.
    • npm ci can only install entire projects at a time: individual dependencies cannot be added with this command.
    • If a node_modules is already present, it will be automatically removed before npm ci begins its install.
    • It will never write to package.json or any of the package-locks: installs are essentially frozen.

    这篇关于是否应该将package-lock.json文件添加到.gitignore?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！