node.js 我是否提交了 npm 5 创建的 package-lock.json 文件？

Do I commit the package-lock.json file created by npm 5?

提问by rink.attendant.6

npm 5 was released todayand one of the new features include deterministic installs with the creation of a package-lock.jsonfile.

npm 5 于今天发布，其中一项新功能包括通过创建package-lock.json文件进行确定性安装。

Is this file supposed to be kept in source control?

这个文件应该保存在源代码管理中吗？

I'm assuming it's similar to yarn.lockand composer.lock, both of which are supposed to be kept in source control.

我假设它类似于yarn.lockand composer.lock，两者都应该保留在源代码管理中。

回答by vine77

Yes, package-lock.jsonis intended to be checked into source control. If you're using npm 5, you may see this on the command line: created a lockfile as package-lock.json. You should commit this file.According to npm help package-lock.json:

是的，package-lock.json旨在签入源代码管理。如果您使用的是 npm 5，您可能会在命令行上看到：created a lockfile as package-lock.json. You should commit this file.根据npm help package-lock.json：

package-lock.jsonis automatically generated for any operations where npm modifies either the node_modulestree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.

This file is intended to be committed into source repositories, and serves various purposes:

• Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.

• Provide a facility for users to "time-travel" to previous states of node_moduleswithout having to commit the directory itself.

• To facilitate greater visibility of tree changes through readable source control diffs.

• And optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.

One key detail about package-lock.jsonis that it cannot be published, and it will be ignored if found in any place other than the toplevel package. It shares a format with npm-shrinkwrap.json(5), which is essentially the same file, but allows publication. This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages.

If both package-lock.jsonand npm-shrinkwrap.jsonare present in the root of a package, package-lock.jsonwill be completely ignored.

package-lock.json对于任何 npm 修改node_modules树或package.json. 它描述了生成的确切树，以便后续安装能够生成相同的树，而不管中间依赖项更新如何。

此文件旨在提交到源存储库中，并用于多种目的：

• 描述依赖树的单一表示，以便保证团队成员、部署和持续集成安装完全相同的依赖关系。

• 为用户“时间旅行”到以前的状态提供便利，node_modules而无需提交目录本身。

• 通过可读的源代码控制差异来促进树更改的更大可见性。

• 并通过允许 npm 跳过先前安装的包的重复元数据解析来优化安装过程。

一个关键的细节package-lock.json是它不能发布，如果在顶级包以外的任何地方发现它都会被忽略。它与 npm-shrinkwrap.json(5) 共享一种格式，它本质上是相同的文件，但允许发布。除非部署 CLI 工具或以其他方式使用发布过程来生成生产包，否则不建议这样做。

如果package-lock.json和npm-shrinkwrap.json都存在于包的根目录中，package-lock.json则将被完全忽略。

回答by xer0x

Yes, it's intended to be checked in. I want to suggest that it gets its own unique commit. We find that it adds a lot of noise to our diffs.

是的，它旨在被签入。我想建议它获得自己独特的提交。我们发现它给我们的差异增加了很多噪音。

回答by k0pernikus

Yes, you SHOULD:

是的你应该：

1. commit the package-lock.json.
2. use npm ciinstead of npm installwhen building your applications both on your CI and your local development machine

1. 提交package-lock.json.
2. npm cinpm install在 CI 和本地开发机器上构建应用程序时使用而不是

The npm ciworkflow requiresthe existence of a package-lock.json.

该npm ci工作流程需要的存在package-lock.json。

---

---

A big downside of npm installcommand is its unexpected behavior that it may mutate the package-lock.json, whereas npm cionly uses the versions specified in the lockfile and produces an error

npm installcommand 的一大缺点是它可能会改变 的意外行为package-lock.json，而npm ci仅使用锁定文件中指定的版本并产生错误

• if the package-lock.jsonand package.jsonare out of sync
• if a package-lock.jsonis missing.

• 如果package-lock.json和package.json不同步
• 如果package-lock.json缺少一个。

Hence, running npm installlocally, esp. in larger teams with multiple developers, may lead to lots of conflicts within the package-lock.jsonand developers to decide to completely delete the package-lock.jsoninstead.

因此，在npm install本地运行，尤其是。在有多个开发人员的较大团队中，可能会导致很多内部冲突package-lock.json，开发人员决定完全删除package-lock.json。

Yet 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.

然而，有一个强大的用例可以相信项目的依赖项在不同机器上以可靠的方式可重复解决。

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.

在过去，我有项目的时候不用package-lock.json/ npm-shrinkwrap.json/yarn.lock文件，它们的构建将失败1天因为随机的依赖有一个破碎的更新。

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

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

If you want to add a new dependency, you still run npm install {dependency}. If you want to upgrade, use either npm update {dependency}or npm install ${dependendency}@{version}and commit the changed package-lock.json.

如果你想添加一个新的依赖，你仍然运行npm install {dependency}. 如果要升级，请使用npm update {dependency}或npm install ${dependendency}@{version}并提交更改的package-lock.json.

If an upgrade fails, you can revert to the last known working package-lock.json.

如果升级失败，您可以恢复到上次已知的工作状态package-lock.json。

---

---

To quote npm doc:

要引用文档NPM：

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或任何包锁：安装基本上是冻结的。

---

---

Note: I posted a similar answer here

注意：我在这里发布了类似的答案

回答by Xin

Yes, the best practice is to check-in (YES, CHECK-IN)

是的，最佳做法是办理登机手续（YES, CHECK-IN）

I agree that it will cause a lot of noise or conflict when seeing the diff. But the benefits are:

我同意在看到差异时会引起很多噪音或冲突。但好处是：

1. guarantee exact same version of every package. This part is the most important when building in different environments at different times. You may use ^1.2.3in your package.json, but how can u ensure each time npm installwill pick up the same version in your dev machine and in the build server, especially those indirect dependency packages? Well, package-lock.jsonwill ensure that. (With the help of npm ciwhich installs packages based on lock file)
2. it improves the installation process.
3. it helps with new audit feature npm audit fix(I think the audit feature is from npm version 6).

1. 保证每个包的版本完全相同。这部分在不同时间在不同环境中构建时是最重要的。您可以^1.2.3在您的 .bashrc 中使用package.json，但是如何确保每次npm install在您的开发机器和构建服务器中都选择相同的版本，尤其是那些间接依赖包？那么，package-lock.json将确保。（借助npm ciwhich 安装基于锁定文件的软件包）
2. 它改进了安装过程。
3. 它有助于新的审计功能npm audit fix（我认为审计功能来自 npm 版本 6）。

回答by Deunz

I don't commit this file in my projects. What's the point ?

我不在我的项目中提交这个文件。重点是什么 ？

1. It's generated
2. It's the cause of a SHA1 code integrity err in gitlab with gitlab-ci.yml builds

1. 它生成了
2. 这是使用 gitlab-ci.yml 构建的 gitlab 中 SHA1 代码完整性错误的原因

Though it's true that I never use ^ in my package.json for libs because I had bad experiences with it.

虽然我从来没有在我的 package.json 中将 ^ 用于库，因为我有过糟糕的经历。

回答by Raza

To the people complaining about the noise when doing git diff:

对于抱怨执行 git diff 时噪音的人：

git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'

What I did was use an alias:

我所做的是使用别名：

alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"

To ignore package-lock.json in diffs for the entire repository (everyone using it), you can add this to .gitattributes:

要忽略整个存储库（每个人都在使用它）的差异中的 package-lock.json，您可以将其添加到.gitattributes：

package-lock.json binary
yarn.lock binary

This will result in diffs that show "Binary files a/package-lock.json and b/package-lock.json differ whenever the package lock file was changed. Additionally, some Git services (notably GitLab, but not GitHub) will also exclude these files (no more 10k lines changed!) from the diffs when viewing online when doing this.

这将导致差异显示“每当包锁定文件更改时，二进制文件 a/package-lock.json 和 b/package-lock.json 就会不同。此外，一些 Git 服务（特别是 GitLab，但不是 GitHub）也将排除执行此操作时在线查看这些文件（不再更改 10k 行！）。

回答by Bablu Singh

Yes, you can commit this file. From the npm's official docs:

是的，您可以提交此文件。来自npm 的官方文档：

package-lock.jsonis automatically generated for any operations where npmmodifies either the node_modulestree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.

This file is intended to be committed into source repositories[.]

package-lock.json为npm修改node_modules树或 的任何操作自动生成package.json。它描述了生成的确切树，以便后续安装能够生成相同的树，而不管中间依赖项更新如何。

该文件旨在提交到源代码库[.]

回答by Balogun Ridwan Ridbay

Disable package-lock.json globally

全局禁用 package-lock.json

type the following in your terminal:

在终端中输入以下内容：

npm config set package-lock false

this really work for me like magic

这真的像魔术一样对我有用

回答by Nikhil Mohadikar

Yes, it's a standard practice to commit package-lock.json

是的，提交 package-lock.json 是标准做法

The main reason for committing package-lock.json is that everyone in the project is on the same package version.

提交 package-lock.json 的主要原因是项目中的每个人都在同一个包版本上。

Pros:-

优点：-

• If you follow strict versioning and don't allow updating to major versions automatically to save yourself from backward-incompatible changes in third-party packages committing package-lock helps a lot.
• If you update a particular package, it gets updated in package-lock.json and everyone using the repository gets updated to that particular version when they take the pull of your changes.

• 如果您遵循严格的版本控制并且不允许自动更新到主要版本以防止第三方软件包中向后不兼容的更改，那么提交 package-lock 会有很大帮助。
• 如果你更新一个特定的包，它会在 package-lock.json 中更新，并且每个使用存储库的人在接受你的更改时都会更新到该特定版本。

Cons:-

缺点：-

• It can make your pull requests look ugly :)'

• 它会让你的拉取请求看起来很难看:)'

Edit:- npm install won't make sure that everyone in the project is on the same package version. npm ci will help with this.

编辑：- npm install 不会确保项目中的每个人都使用相同的包版本。npm ci 将对此有所帮助。

回答by MagicLAMP

My use of npm is to generate minified/uglified css/js and to generate the javascript needed in pages served by a django application. In my applications, Javascript runs on the page to create animations, some times perform ajax calls, work within a VUE framework and/or work with the css. If package-lock.json has some overriding control over what is in package.json, then it may be necessary that there is one version of this file. In my experience it either does not effect what is installed by npm install, or if it does, It has not to date adversely affected the applications I deploy to my knowledge. I don't use mongodb or other such applications that are traditionally thin client.

我对 npm 的使用是生成缩小/丑化的 css/js 并生成 django 应用程序提供的页面中所需的 javascript。在我的应用程序中，Javascript 在页面上运行以创建动画，有时执行 ajax 调用，在 VUE 框架内工作和/或使用 css。如果 package-lock.json 对 package.json 中的内容有一些覆盖控制，则可能需要此文件的一个版本。根据我的经验，它要么不影响 npm install 安装的内容，要么如果影响了，它迄今为止还没有对我部署的应用程序产生不利影响。我不使用 mongodb 或其他传统上属于瘦客户端的应用程序。

I remove package-lock.json from repo because npm install generates this file, and npm install is part of the deploy process on each server that runs the app. Version control of node and npm are done manually on each server, but I am careful that they are the same.

我从 repo 中删除了 package-lock.json，因为 npm install 会生成这个文件，并且 npm install 是运行应用程序的每台服务器上部署过程的一部分。node 和 npm 的版本控制是在每台服务器上手动完成的，但我很小心它们是相同的。

When npm installis run on the server, it changes package-lock.json, and if there are changes to a file that is recorded by the repo on the server, the next deploy WONT allow you to pull new changes from origin. That is you can't deploy because the pull will overwrite the changes that have been made to package-lock.json.

在npm install服务器上运行时，它会更改 package-lock.json，如果服务器上的 repo 记录的文件发生更改，则下一次部署 WONT 允许您从源中提取新更改。那是您无法部署，因为 pull 将覆盖对 package-lock.json 所做的更改。

You can't even overwrite a locally generated package-lock.json with what is on the repo (reset hard origin master), as npm will complain when ever you issue a command if the package-lock.json does not reflect what is in node_modules due to npm install, thus breaking the deploy. Now if this indicates that slightly different versions have been installed in node_modules, once again that has never caused me problems.

你甚至不能用 repo 上的内容覆盖本地生成的 package-lock.json（重置硬源主机），因为如果 package-lock.json 没有反映里面的内容，npm 会在你发出命令时抱怨node_modules 由于 npm install，从而破坏了部署。现在，如果这表明 node_modules 中安装了略有不同的版本，那么这再一次从未给我带来问题。

If node_modules is not on your repo (and it should not be), then package-lock.json should be ignored.

如果 node_modules 不在你的仓库中（也不应该在），那么 package-lock.json 应该被忽略。

If I am missing something, please correct me in the comments, but the point that versioning is taken from this file makes no sense. The file package.json has version numbers in it, and I assume this file is the one used to build packages when npm install occurs, as when I remove it, npm install complains as follows:

如果我遗漏了什么，请在评论中纠正我，但是从这个文件中获取版本控制的观点是没有意义的。文件 package.json 中有版本号，我假设这个文件是在 npm install 发生时用于构建包的文件，因为当我删除它时， npm install 抱怨如下：

jason@localhost:introcart_wagtail$ rm package.json
jason@localhost:introcart_wagtail$ npm install
npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

and the build fails, however when installing node_modules or applying npm to build js/css, no complaint is made if I remove package-lock.json

并且构建失败，但是在安装 node_modules 或应用 npm 构建 js/css 时，如果我删除 package-lock.json，则不会有任何抱怨

jason@localhost:introcart_wagtail$ rm package-lock.json 
jason@localhost:introcart_wagtail$ npm run dev

> [email protected] dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

 10% building 0/1 modules 1 active ...