npm5今天发布,其中一个新特性包括通过创建package-lock.json文件进行确定性安装。
这个文件应该保存在源代码管理中吗?
我假设它类似于yarn.lock和composer.lock,它们都应该保存在源代码控制中。
npm5今天发布,其中一个新特性包括通过创建package-lock.json文件进行确定性安装。
这个文件应该保存在源代码管理中吗?
我假设它类似于yarn.lock和composer.lock,它们都应该保存在源代码控制中。
当前回答
将package-lock.json提交到源代码版本控制意味着项目将使用特定版本的依赖项,该依赖项可能与package.json中定义的依赖项相匹配,也可能与之不匹配。虽然依赖项具有特定版本,但如您所见,没有任何Caret(^)和Tilde(~),这意味着依赖项不会更新到最新版本。npm install将获取当前版本Angular所需的相同版本。
注意:package-lock.json强烈建议在CI期间将任何Caret(^)和Tilde(~)添加到要更新的依赖项时提交它。
其他回答
所有答案都说“是”,但这也取决于项目,医生说:
package-lock.json的一个关键细节是它不能被发布,如果在顶层包之外的任何地方找到它,就会被忽略。
这意味着你不需要在npm上发布依赖的package-lock.json,但你需要在repo中使用package-llock.json来锁定测试依赖的版本,构建依赖…
但是,如果您使用lerna来管理具有多个包的项目,那么应该只将package.json放在repo的根目录上,而不是放在每个子包中。你会得到这样的结果:
.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
对于那些抱怨做gitdiff时噪音的人:
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'"
要忽略整个存储库(每个人都使用它)diffs中的package-lock.json,可以将其添加到.gitattributes中:
package-lock.json binary
yarn.lock binary
这将导致diff显示“每当包锁定文件更改时,二进制文件a/package-lock.json和b/package-llock.json都不同。此外,一些Git服务(特别是GitLab,但不是GitHub)也会在进行此操作时从diff中排除这些文件(没有超过10k行更改!)。
是的,package-lock.json打算签入源代码管理。如果您使用的是npm5+,您可能会在命令行上看到以下通知:创建了一个名为package-lock.json的锁定文件。您应该提交该文件。根据npm帮助package-lock.json:
package-lock.json是为npm所在的任何操作自动生成的修改node_modules树或package.json生成的确切树,以便后续安装能够生成相同的树,而不考虑中间的依赖关系更新。此文件旨在提交到源存储库中各种用途:描述依赖关系树的单一表示,以确保队友、部署和持续集成能够安装完全相同的依赖关系。为用户提供一种工具,让他们“时间旅行”到node_module的先前状态,而不必提交目录本身。通过可读的源代码控制差异,帮助提高树更改的可见性。并通过允许npm跳过先前安装的包的重复元数据解析来优化安装过程。package-lock.json的一个关键细节是它无法发布如果在顶层包以外的任何位置找到,将被忽略。它共享npm-shrinkwrap.json格式,基本上是相同的文件,但是允许发布。除非部署CLI工具或否则使用发布过程来生产生产包。如果package-lock.json和npm-shrinkwrap.json都存在于包package-lock.json将被完全忽略。
是的,最佳做法是办理登机手续(是,办理登机手续)
我同意,当看到差异时,这会引起很多噪音或冲突。但好处是:
确保开发环境和生产环境之间的每个包的版本完全相同。当在不同的时间在不同的环境中构建时,这一部分是最重要的。您可以在package.json中使用^1.2.3,但如何确保每次npm安装都会在开发机器和构建服务器中获得相同的版本,尤其是那些间接依赖包?好吧,package-lock.json将确保这一点。(借助基于锁文件安装软件包的npm-ci)它改进了安装过程。它有助于新的审计功能npm审计修复。
我不在项目中提交此文件。有什么意义?
它是生成的这是gitlab-ci.yml构建的gitlab中SHA1代码完整性错误的原因
虽然我确实从未在package.json中使用^作为libs,因为我有过不好的体验。