不可以,不应将 添加到 。相反,我强烈建议:package-lock.json
.gitignore
- 将
package-lock.json
u 添加到您的版本控制存储库
-
在本地和部署管道中生成应用程序时,请使用 npm
ci
而不是 npm install
。
(该命令自 npm@5.7 起可用,如果有疑问,请通过:.) 升级您的 npm。
ci
npm install -g npm
该命令的最大缺点之一是其意外行为,它可能会改变 ,而仅使用 lockfile 中的版本,并在 和 不同步时产生错误。npm install
package-lock.json
npm ci
package-lock.json
package.json
此外,需要存在,如果不存在,则会打印错误。有一个强大的用例,能够相信项目的依赖关系在不同的机器上以可靠的方式重复解决。npm ci
package-lock.json
此外,在添加依赖项之前,会对整个文件夹进行 nuke,以确保您使用实际的依赖项而不是本地更改,同时仍然比正常版本快。npm ci
node_modules
npm install
从 a 中可以得到确切的结果:一个已知的工作状态,始终具有完全相同的依赖关系树。package-lock.json
过去,我有一些没有/ / 文件的项目,它们的构建有一天会失败,因为随机依赖关系得到了一个中断的更新。(虽然许多库都遵守 semvar 版本控制指南,但您不能保证它们不会在次要升级时中断。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 更新
- 运行测试
- 如果测试通过,则提交并推送到存储库
- 否则失败并报告要手动解决的问题
这是我会在CI服务器上看到的托管的东西,例如Jenkins,并且不应该通过上述原因通过将文件添加到..gitignore
或者引用npm文档:
强烈建议您将生成的包锁提交到源代码管理:这将允许团队中的其他任何人、部署、CI/持续集成以及在包源中运行 npm install 的任何其他人获得与开发时完全相同的依赖关系树。此外,这些更改的差异是人类可读的,并将通知你 npm 对node_modules所做的任何更改,以便你可以注意到是否有任何传递依赖项已更新、提升等。
关于npm ci
与npm安装
之间的区别:
- 项目必须具有现有的 package-lock.json 或 npm-shrinkwrap.json。
- 如果包锁中的依赖项与 package.json 中的依赖项不匹配,则将退出并显示错误,而不是更新包锁。
npm ci
-
npm ci
一次只能安装整个项目:不能使用此命令添加单个依赖项。
- 如果 已存在,则在开始安装之前将自动将其删除。
node_modules
npm ci
- 它永远不会写入或任何软件包锁:安装基本上是冻结的。
package.json