npm5今天发布,其中一个新特性包括通过创建package-lock.json文件进行确定性安装。

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

我假设它类似于yarn.lock和composer.lock,它们都应该保存在源代码控制中。


当前回答

是的,最佳做法是办理登机手续(是,办理登机手续)

我同意,当看到差异时,这会引起很多噪音或冲突。但好处是:

确保开发环境和生产环境之间的每个包的版本完全相同。当在不同的时间在不同的环境中构建时,这一部分是最重要的。您可以在package.json中使用^1.2.3,但如何确保每次npm安装都会在开发机器和构建服务器中获得相同的版本,尤其是那些间接依赖包?好吧,package-lock.json将确保这一点。(借助基于锁文件安装软件包的npm-ci)它改进了安装过程。它有助于新的审计功能npm审计修复。

其他回答

是的,最佳做法是办理登机手续(是,办理登机手续)

我同意,当看到差异时,这会引起很多噪音或冲突。但好处是:

确保开发环境和生产环境之间的每个包的版本完全相同。当在不同的时间在不同的环境中构建时,这一部分是最重要的。您可以在package.json中使用^1.2.3,但如何确保每次npm安装都会在开发机器和构建服务器中获得相同的版本,尤其是那些间接依赖包?好吧,package-lock.json将确保这一点。(借助基于锁文件安装软件包的npm-ci)它改进了安装过程。它有助于新的审计功能npm审计修复。

是的,您应该:

提交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安装,特别是在具有多个开发人员的大型团队中,可能会导致package-lock.json内部发生大量冲突,开发人员决定完全删除package-llock.json。

然而,有一个强大的用例可以证明,项目的依赖关系可以在不同的机器上以可靠的方式重复解决。

从package-lock.json中,您可以得到确切的结果:已知工作状态。

过去,我有一些没有package-lock.json/npm-shrinkwrap.json/yarn.lock文件的项目,它们的构建有一天会失败,因为一个随机依赖项得到了破坏性的更新。

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

如果要添加新的依赖项,仍然可以运行npm install{dependency}。如果要升级,请使用npm update{dependency}或npm install${dependency}@{version}并提交更改的package-lock.json。

如果升级失败,您可以恢复到最后一个已知的工作包-lock.json。


引用npm文档:

强烈建议您将生成的包锁提交到源代码管理:这将允许团队中的任何其他人部署、您的CI/持续集成以及任何其他运行在包源中安装npm,以获得完全相同的依赖关系此外更改是人类可读的,并将通知您npm的任何更改设置为node_modules,因此您可以注意到依赖关系得到更新、提升等。

关于npm ci与npm install之间的区别:

项目必须具有现有的package-lock.json或npm-shrinkwrap.json。如果包锁中的依赖项与package.json中的依赖不匹配,npm-ci将退出并返回错误,而不是更新包裹锁。npmci一次只能安装整个项目:不能使用此命令添加单个依赖项。如果node_modules已经存在,则在npm-ci开始安装之前,它将被自动删除。它永远不会写入package.json或任何包锁:安装基本上是冻结的。


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

将package-lock.json提交到源代码版本控制意味着项目将使用特定版本的依赖项,该依赖项可能与package.json中定义的依赖项相匹配,也可能与之不匹配。虽然依赖项具有特定版本,但如您所见,没有任何Caret(^)和Tilde(~),这意味着依赖项不会更新到最新版本。npm install将获取当前版本Angular所需的相同版本。

注意:package-lock.json强烈建议在CI期间将任何Caret(^)和Tilde(~)添加到要更新的依赖项时提交它。

是的,您可以提交此文件。根据npm的官方文件:

对于npm修改node_modules树或package.json的任何操作,package-lock.json都会自动生成。它描述了生成的确切树,以便后续安装能够生成相同的树,而不考虑中间的依赖关系更新。此文件旨在提交到源存储库[.]中

我不在项目中提交此文件。有什么意义?

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

虽然我确实从未在package.json中使用^作为libs,因为我有过不好的体验。