您应该将package-lock.json添加到版本控制存储库中.

我还强烈建议在构建应用程序时使用npm ci而不是npm install,并且该工作流程需要包含lock-lock.json. (npm install命令最大的缺点之一是它可能会改变package-lock.json,而npm ci只使用lockfile中的版本,如果package-lock.json和package.json不在,则会产生错误同步.)

有一个强大的用例,可以相信项目的依赖关系可以在不同的机器上以可靠的方式重复解决.

从package-lock.json中你可以得到：一个已知的工作状态.

在过去,我有没有package-lock.json / shrinkwrap / yarn.lock文件的项目,这些文件的构建将在一天内失败,因为随机依赖关系会有更新.这些问题有时难以解决,因为您有时不得不猜测最后一个工作版本是什么.

关于测试项目的最新依赖项：这是npm update的用途,我认为它应该由开发人员运行,开发人员也在本地运行测试,如果出现问题则解决问题,然后谁提交改变了package-lock.json. (如果升级失败,我可以恢复到最后一个工作包-lock.json.)

此外,我很少一次升级所有依赖项,但有时我会挑选我需要的更新.这是我将其视为手动维护步骤的另一个原因.

如果您想让它自动化,您可以创建一份工作：

>结账仓库
>运行npm update
>运行测试

>如果测试通过,则提交并推送到存储库
>其他失败并报告问题需要手动解决

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

或者到quote 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.

关于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.