我是否提交由 npm 5 创建的 package-lock.json 文件？
Do I commit the package-lock.json file created by npm 5?
npm 5 was released today 其中一项新功能包括通过创建 package-lock.json 文件进行确定性安装。
这个文件应该保存在源代码管理中吗？
我假设它类似于 and composer.lock，两者都应该保存在源代码管理中。
是的，package-lock.json 旨在签入源代码管理。如果您使用的是 npm 5+，您可能会在命令行中看到此通知：created a lockfile as package-lock.json. You should commit this file. 根据 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. 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.
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.json is 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, 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.json and npm-shrinkwrap.json are present in the root of
a package, package-lock.json will be completely ignored.
是的，它打算被签入。我想建议它获得自己独特的提交。我们发现它给我们的差异增加了很多噪音。
是的，您可以提交此文件。来自 npm's official docs:
package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, 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[.]
是的，最好的做法是签到（YES，CHECK-IN）
我同意看到差异时会引起很多噪音或冲突。但好处是：
- 保证每个包的版本完全相同。这部分是在不同的时间不同的环境中构建时最重要的。您可以在
package.json 中使用 ^1.2.3，但是您如何确保每次 npm install 都会在您的开发机器和构建服务器中选择相同的版本，尤其是那些间接依赖包？好吧，package-lock.json 会确保这一点。 （借助 npm ci 根据锁定文件安装软件包）
- 它改进了安装过程。
- 它有助于新的审核功能
npm audit fix（我认为审核功能来自 npm 版本 6）。
致那些在做 git diff 时抱怨噪音的人：
git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'
我所做的是使用别名：
alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"
要忽略整个存储库（每个人都在使用它）的差异中的 package-lock.json，您可以将其添加到 .gitattributes:
package-lock.json binary
yarn.lock binary
这将导致差异显示“二进制文件 a/package-lock.json 和 b/package-lock.json 在包锁定文件更改时不同。此外，一些Git 服务（特别是 GitLab，但不是 GitHub）也会在在线查看时从差异中排除这些文件（不再更改 10k 行！）。
我没有在我的项目中提交这个文件。有什么意义？
- 已生成
- 这是在 gitlab 中使用 gitlab-ci.yml builds
导致 SHA1 代码完整性错误的原因
虽然我从来没有在我的 package.json 库中使用 ^ 是真的，因为我有过不好的经历。
全局禁用包-lock.json
在您的终端中输入以下内容：
npm config set package-lock false
这对我来说真的很神奇
我对 npm 的使用是生成 minified/uglified css/js 并生成 django 应用程序服务的页面所需的 javascript。在我的应用程序中，Javascript 运行 在页面上创建动画，有时执行 ajax 调用，在 VUE 框架内工作 and/or 使用 css .如果 package-lock.json 对 package.json 中的内容有一些压倒一切的控制，那么这个文件可能有一个版本。根据我的经验，它要么不会影响 npm install 安装的内容，要么即使影响了，但据我所知，它迄今为止还没有对我部署的应用程序产生不利影响。我不使用 mongodb 或其他传统瘦客户端应用程序。
我从 repo 中删除包-lock.json
因为 npm install 会生成此文件，并且 npm install 是 运行 应用程序的每台服务器上的部署过程的一部分。 node 和 npm 的版本控制是在每个服务器上手动完成的，但我很小心它们是相同的。
当npm install在服务器上为运行时，它改变了package-lock.json，
如果服务器上的 repo 记录的文件发生更改，则下一次部署 WONT 允许您从源中提取新的更改。那是
您无法部署，因为拉取将覆盖对 package-lock.json 所做的更改。
你甚至不能用 repo 上的内容覆盖本地生成的 package-lock.json（重置 hard origin master），因为如果 package-[=由于 npm install，31=] 不反映 node_modules 中的内容，因此破坏了部署。现在，如果这表明在 node_modules 中安装了略有不同的版本，那再一次从未给我带来问题。
如果 node_modules 不在您的仓库中（不应该在），则应忽略 package-lock.json。
如果我遗漏了什么，请在评论中纠正我，但是从这个文件中获取版本控制的观点是没有意义的。文件 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'
并且构建失败，但是当安装 node_modules 或应用 npm 构建 js/css 时，如果我删除 package-lock.json
则没有投诉
jason@localhost:introcart_wagtail$ rm package-lock.json
jason@localhost:introcart_wagtail$ npm run dev
> introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development
10% building 0/1 modules 1 active ...
是的，你应该：
- 提交
package-lock.json。
- 在 CI 和本地开发机器
上构建应用程序时使用 npm ci 而不是 npm install
npm ci 工作流 需要 package-lock.json。
npm install 命令的一大缺点是它的意外行为可能会改变 package-lock.json，而 npm ci 仅使用锁定文件中指定的版本并产生错误
- 如果
package-lock.json 和 package.json 不同步
- 如果缺少
package-lock.json。
因此，运行在本地npm install，特别是。在拥有多个开发人员的大型团队中，可能会导致 package-lock.json 内部发生大量冲突，开发人员决定完全删除 package-lock.json。
然而，有一个强大的 use-case 能够相信项目的依赖项在不同机器上以可靠的方式重复解析。
从 package-lock.json 你得到的正是：known-to-work 状态。
过去，我的项目没有 package-lock.json / npm-shrinkwrap.json / yarn.lock 文件，它们的构建有一天会失败，因为随机依赖项得到了破坏性更新。
这些问题很难解决，因为您有时不得不猜测最后一个工作版本是什么。
如果要添加新的依赖，你还是运行npm install {dependency}。如果要升级，请使用 npm update {dependency} 或 npm install ${dependendency}@{version} 并提交更改后的 package-lock.json.
如果升级失败，您可以恢复到上次已知的工作 package-lock.json。
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.
关于difference between npm ci vs npm 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 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 是标准做法。
提交 package-lock.json 的主要原因是项目中的每个人都使用相同的包版本。
优点：
- 如果您遵循严格的版本控制并且不允许自动更新到主要版本以避免 backward-incompatible 更改 third-party 包中的更改，提交 package-lock 会有很大帮助。
- 如果您更新特定的包，它会在 package-lock 中更新。json 并且使用存储库的每个人在接受您的更改时都会更新到该特定版本。
缺点：
- 它会让你的拉取请求看起来很丑:)
npm install 无法确保项目中的每个人都使用相同的包版本。 npm ci 将对此有所帮助。
所有答案都说“是”，但这也取决于项目，文档说：
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.
这意味着你不需要在 npm 上发布你的 package-lock.json 依赖，但你需要在你的 repo 中使用 package-lock.json 来锁定你的测试依赖的版本，构建依赖......
但是，如果您使用 lerna 来管理包含多个包的项目，您应该将 package.json 仅放在您的存储库的根目录中，而不是在每个子包中使用 npm init.你会得到类似的东西:
.git
lerna.json
package.json
package-lock.json <--- here
packages/a/package.json
packages/a/lib/index.js
packages/b/package.json
packages/b/lib/index.js
将 package-lock.json 提交到源代码版本控制意味着该项目将使用特定版本的依赖项，该版本可能与 package.json 中定义的依赖项匹配，也可能不匹配。虽然依赖项有一个没有任何插入符 (^) 和波浪符 (~) 的特定版本，如您所见，这意味着依赖项不会更新到最新版本。并且 npm install 将选择相同的版本以及我们当前版本 Angular.
需要的版本
注意：package-lock.json 强烈建议提交它，如果我在 CI.[=10= 期间将任何插入符 (^) 和波浪符 (~) 添加到要更新的依赖项中]
npm 5 was released today 其中一项新功能包括通过创建 package-lock.json 文件进行确定性安装。
这个文件应该保存在源代码管理中吗？
我假设它类似于 composer.lock，两者都应该保存在源代码管理中。
是的，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 thenode_modulestree, orpackage.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, 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.jsonandnpm-shrinkwrap.jsonare present in the root of a package,package-lock.jsonwill be completely ignored.
是的，它打算被签入。我想建议它获得自己独特的提交。我们发现它给我们的差异增加了很多噪音。
是的，您可以提交此文件。来自 npm's official docs:
package-lock.jsonis automatically generated for any operations wherenpmmodifies either thenode_modulestree, orpackage.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[.]
是的，最好的做法是签到（YES，CHECK-IN）
我同意看到差异时会引起很多噪音或冲突。但好处是：
- 保证每个包的版本完全相同。这部分是在不同的时间不同的环境中构建时最重要的。您可以在
package.json中使用^1.2.3，但是您如何确保每次npm install都会在您的开发机器和构建服务器中选择相同的版本，尤其是那些间接依赖包？好吧，package-lock.json会确保这一点。 （借助npm ci根据锁定文件安装软件包） - 它改进了安装过程。
- 它有助于新的审核功能
npm audit fix（我认为审核功能来自 npm 版本 6）。
致那些在做 git diff 时抱怨噪音的人：
git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'
我所做的是使用别名：
alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"
要忽略整个存储库（每个人都在使用它）的差异中的 package-lock.json，您可以将其添加到 .gitattributes:
package-lock.json binary
yarn.lock binary
这将导致差异显示“二进制文件 a/package-lock.json 和 b/package-lock.json 在包锁定文件更改时不同。此外，一些Git 服务（特别是 GitLab，但不是 GitHub）也会在在线查看时从差异中排除这些文件（不再更改 10k 行！）。
我没有在我的项目中提交这个文件。有什么意义？
- 已生成
- 这是在 gitlab 中使用 gitlab-ci.yml builds 导致 SHA1 代码完整性错误的原因
虽然我从来没有在我的 package.json 库中使用 ^ 是真的，因为我有过不好的经历。
全局禁用包-lock.json
在您的终端中输入以下内容：
npm config set package-lock false
这对我来说真的很神奇
我对 npm 的使用是生成 minified/uglified css/js 并生成 django 应用程序服务的页面所需的 javascript。在我的应用程序中，Javascript 运行 在页面上创建动画，有时执行 ajax 调用，在 VUE 框架内工作 and/or 使用 css .如果 package-lock.json 对 package.json 中的内容有一些压倒一切的控制，那么这个文件可能有一个版本。根据我的经验，它要么不会影响 npm install 安装的内容，要么即使影响了，但据我所知，它迄今为止还没有对我部署的应用程序产生不利影响。我不使用 mongodb 或其他传统瘦客户端应用程序。
我从 repo 中删除包-lock.json 因为 npm install 会生成此文件，并且 npm install 是 运行 应用程序的每台服务器上的部署过程的一部分。 node 和 npm 的版本控制是在每个服务器上手动完成的，但我很小心它们是相同的。
当npm install在服务器上为运行时，它改变了package-lock.json，
如果服务器上的 repo 记录的文件发生更改，则下一次部署 WONT 允许您从源中提取新的更改。那是
您无法部署，因为拉取将覆盖对 package-lock.json 所做的更改。
你甚至不能用 repo 上的内容覆盖本地生成的 package-lock.json（重置 hard origin master），因为如果 package-[=由于 npm install，31=] 不反映 node_modules 中的内容，因此破坏了部署。现在，如果这表明在 node_modules 中安装了略有不同的版本，那再一次从未给我带来问题。
如果 node_modules 不在您的仓库中（不应该在），则应忽略 package-lock.json。
如果我遗漏了什么，请在评论中纠正我，但是从这个文件中获取版本控制的观点是没有意义的。文件 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'
并且构建失败，但是当安装 node_modules 或应用 npm 构建 js/css 时，如果我删除 package-lock.json
则没有投诉jason@localhost:introcart_wagtail$ rm package-lock.json
jason@localhost:introcart_wagtail$ npm run dev
> introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development
10% building 0/1 modules 1 active ...
是的，你应该：
- 提交
package-lock.json。 - 在 CI 和本地开发机器 上构建应用程序时使用
npm ci 而不是 npm install
npm ci 工作流 需要 package-lock.json。
npm install 命令的一大缺点是它的意外行为可能会改变 package-lock.json，而 npm ci 仅使用锁定文件中指定的版本并产生错误
- 如果
package-lock.json和package.json不同步 - 如果缺少
package-lock.json。
因此，运行在本地npm install，特别是。在拥有多个开发人员的大型团队中，可能会导致 package-lock.json 内部发生大量冲突，开发人员决定完全删除 package-lock.json。
然而，有一个强大的 use-case 能够相信项目的依赖项在不同机器上以可靠的方式重复解析。
从 package-lock.json 你得到的正是：known-to-work 状态。
过去，我的项目没有 package-lock.json / npm-shrinkwrap.json / yarn.lock 文件，它们的构建有一天会失败，因为随机依赖项得到了破坏性更新。
这些问题很难解决，因为您有时不得不猜测最后一个工作版本是什么。
如果要添加新的依赖，你还是运行npm install {dependency}。如果要升级，请使用 npm update {dependency} 或 npm install ${dependendency}@{version} 并提交更改后的 package-lock.json.
如果升级失败，您可以恢复到上次已知的工作 package-lock.json。
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.
关于difference between npm ci vs npm 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 beforenpm cibegins its install.- It will never write to
package.jsonor any of the package-locks: installs are essentially frozen.
注意：我贴了一个类似的回答
是的，提交 package-lock.json 是标准做法。
提交 package-lock.json 的主要原因是项目中的每个人都使用相同的包版本。
优点：
- 如果您遵循严格的版本控制并且不允许自动更新到主要版本以避免 backward-incompatible 更改 third-party 包中的更改，提交 package-lock 会有很大帮助。
- 如果您更新特定的包，它会在 package-lock 中更新。json 并且使用存储库的每个人在接受您的更改时都会更新到该特定版本。
缺点：
- 它会让你的拉取请求看起来很丑:)
npm install 无法确保项目中的每个人都使用相同的包版本。 npm ci 将对此有所帮助。
所有答案都说“是”，但这也取决于项目，文档说：
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.
这意味着你不需要在 npm 上发布你的 package-lock.json 依赖，但你需要在你的 repo 中使用 package-lock.json 来锁定你的测试依赖的版本，构建依赖......
但是，如果您使用 lerna 来管理包含多个包的项目，您应该将 package.json 仅放在您的存储库的根目录中，而不是在每个子包中使用 npm init.你会得到类似的东西:
.git
lerna.json
package.json
package-lock.json <--- here
packages/a/package.json
packages/a/lib/index.js
packages/b/package.json
packages/b/lib/index.js
将 package-lock.json 提交到源代码版本控制意味着该项目将使用特定版本的依赖项，该版本可能与 package.json 中定义的依赖项匹配，也可能不匹配。虽然依赖项有一个没有任何插入符 (^) 和波浪符 (~) 的特定版本，如您所见，这意味着依赖项不会更新到最新版本。并且 npm install 将选择相同的版本以及我们当前版本 Angular.
需要的版本注意：package-lock.json 强烈建议提交它，如果我在 CI.[=10= 期间将任何插入符 (^) 和波浪符 (~) 添加到要更新的依赖项中]