是否提交由npm 5创建的package-lock.json文件？

本文翻译自：Do I commit the package-lock.json file created by npm 5?

npm 5 was released today and one of the new features include deterministic installs with the creation of a package-lock.json file. npm 5已于今天发布 ，其中一项新功能包括通过安装package-lock.json文件进行确定性安装。

Is this file supposed to be kept in source control? 该文件应该保留在源代码管理中吗？

I'm assuming it's similar to yarn.lock and composer.lock , both of which are supposed to be kept in source control. 我假设它类似于yarn.lock和composer.lock ，它们都应该保留在源代码控制中。

---

#1楼

参考：https://stackoom.com/question/2zUCc/是否提交由npm-创建的package-lock-json文件

---

#2楼

Yes, package-lock.json is intended to be checked into source control. 是的， package-lock.json用于检查到源代码管理中。 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. 如果您使用的是npm 5，则可能会在命令行上看到此信息： created a lockfile as package-lock.json. You should commit this file. created a lockfile as package-lock.json. You should commit this file. According to npm help package-lock.json : 根据npm help package-lock.json ：

package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json . 对于npm修改node_modules树或package.json任何操作，都会自动生成package-lock.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_modules without having to commit the directory itself. 为用户提供一种工具，使其可以“时间旅行”到node_modules先前状态，而不必提交目录本身。

• 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. 并允许npm跳过先前安装的软件包的重复元数据解析，从而优化安装过程。

One key detail about package-lock.json is that it cannot be published, and it will be ignored if found in any place other than the toplevel package. 关于package-lock.json一个关键细节是它无法发布，并且如果在顶级软件包之外的任何地方都将被忽略。 It shares a format with npm-shrinkwrap.json(5), which is essentially the same file, but allows publication. 它与npm-shrinkwrap.json（5）共享一种格式，该格式本质上是相同的文件，但是可以发布。 This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages. 除非部署CLI工具或使用发布过程来生产生产软件包，否则不建议这样做。

If both package-lock.json and npm-shrinkwrap.json are present in the root of a package, package-lock.json will be completely ignored. 如果package-lock.json和npm-shrinkwrap.json package-lock.json都存在于包的根目录中，则package-lock.json将被完全忽略。

---

#3楼

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. 我们发现它为我们的差异增加了很多噪音。

---

#4楼

Yes, you can commit this file. 是的，您可以提交此文件。 From the npm's official docs : 来自npm的官方文档 ：

package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json . 对于npm修改node_modules树或package.json任何操作，都会自动生成package-lock.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[.] 该文件旨在提交到源存储库中。

---

#5楼

Yes, the best practice is to 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.3 in your package.json , but how can u ensure each time npm install will pick up the same version in your dev machine and in the build server, especially those indirect dependency packages? 您可以在package.json使用^1.2.3 ，但是如何确保每次npm install在您的开发机和构建服务器中都选择相同的版本，尤其是那些间接依赖程序包？ Well, package-lock.json will ensure that. 好了， package-lock.json将确保这一点。 (With the help of npm ci which installs packages based on lock file) （在npm ci的帮助下， npm ci根据锁定文件安装软件包）
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). 它有助于新的审核功能npm audit fix （我认为审核功能来自npm版本6）。

---

#6楼

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 : 要忽略整个存储库（每个使用它的人）在diffs中的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行！）来自差异文件。