不,不应将
package-lock.json
添加到
.gitignore
中。相反,我强烈建议:
- 将
package-lock.json
添加到版本控制存储库中
- 在本地构建应用程序和部署管道时使用
npm ci
而不是npm install
。(ci
命令自npm@5.7以来可用,如果有疑问,请通过以下方式升级npm:
npm install -g npm
)
npm install
命令最大的缺点之一是其可能会改变
package-lock.json
文件,而
npm ci
仅使用锁定文件中的版本,如果
package-lock.json
和
package.json
不同步,则会产生错误。此外,
npm ci
需要存在一个
package-lock.json
,否则会打印出错误信息。在不同机器上可靠地重复解析项目依赖项有很强的用例。此外,
npm ci
在添加依赖项之前会清空整个
node_modules
文件夹,以确保您使用的是实际依赖项,而不是本地更改,同时速度比普通的
npm install
更快。通过
package-lock.json
,您可以获得一个已知工作状态,具有完全相同的依赖树。过去,我曾经有一些没有
package-lock.json
/
npm-shrinkwrap.json
/
yarn.lock
文件的项目,由于随机依赖项进行了破坏性更新,它们的构建会在某一天失败。这些问题很难解决,因为有时您必须猜测最后一个有效版本是哪个。
关于测试项目的最新依赖项:这就是
npm update
的用途,我认为应该由开发人员执行,他们还应该在本地运行测试,解决可能出现的问题,然后提交更改的
package-lock.json
。(如果升级失败,可以恢复到上一个工作的
package-lock.json
。)
此外,我很少一次性升级所有依赖项(因为这也可能需要进一步的维护),而是选择我需要更新的内容(例如,
npm update {dependency}
或
npm install {dependency}@2.1.3
)。这也是为什么我认为它是手动维护步骤的另一个原因。
如果你真的想自动化它,你可以创建一个作业来完成以下任务:
- 检查存储库
- 运行 npm update
- 运行测试
- 如果测试通过,则提交并推送到存储库
- 否则失败并报告问题以手动解决
我认为这应该托管在 CI 服务器上,例如 Jenkins,并且不应该通过将文件添加到
.gitignore
来实现。
或者按照npm文档建议:
强烈建议将生成的包锁提交到源代码控制:这将允许您团队中的任何其他人、您的部署、您的CI/持续集成以及在您的软件包源中运行npm install的任何其他人都能获得与您正在开发的完全相同的依赖项树。此外,这些更改的差异是人类可读的,并将通知您npm对node_modules所做的任何更改,因此您可以注意到是否更新了任何传递依赖项、提升等。
关于npm ci与npm install之间的区别, 请参考以下内容:
- 该项目必须有现有的package-lock.json或npm-shrinkwrap.json。
- 如果包锁中的依赖项与package.json中的依赖项不匹配,则
npm ci
将退出错误,而不是更新包锁。
npm ci
只能一次安装整个项目:不能使用此命令添加单个依赖项。
- 如果已经存在
node_modules
,则在npm ci
开始安装之前,它将自动删除。
- 它永远不会写入
package.json
或任何包锁:安装基本上是冻结的。