package-lock.json的作用

什么是package-lock.json

在前端项目根目录里有一个package-lock.json文件,有同学疑惑这个文件是干嘛用,不是已经有一个package文件了吗?这个文件前身是npm-shrinkwrap.json,因为npm的依赖管理非常宽松,一个项目在同一天内都可能会安装到不同版本的依赖包,依赖包的升级可能会给项目带来bug。

这时shrinkwrap就应运而生,但是大家都懒得写,所以npm在5+版本之后,收到yarn.lock的启发,默认会在安装时生成package-loack文件。


举个例子

总结

package-lock是用来严格控制版本依赖的。

package-lock.json 详细解析

package-lock.json会为npm修改node_modules树或的任何操作自动生成package.json。它描述了生成的确切树,因此无论中间依赖项更新如何,后续安装都可以生成相同的树。该文件旨在提交到源存储库中,并具有多种用途:

  • 描述依赖关系树的单个表示,这样可以确保队友,部署和持续集成安装完全相同的依赖关系。
  • 为用户提供一种工具,使其可以“时间旅行”到以前的状态,node_modules而不必提交目录本身。
  • 为了通过可读的源代码控制差异更好地了解树的变化。
  • 并允许npm跳过以前安装的软件包的重复元数据解析,从而优化安装过程。

关于package-lock.json它的一个关键细节是它无法发布,并且如果在顶级软件包之外的任何地方找到它,它将被忽略。它与共享格式npm-shrinkwrap.json,该文件本质上是相同的文件,但可以发布。除非部署CLI工具或使用发布过程来生产生产软件包,否则不建议这样做。如果软件包的根目录中同时存在package-lock.jsonnpm-shrinkwrap.jsonpackage-lock.json将被完全忽略。

文件格式

name

这是程序包锁定的程序包名称。这必须与中的内容匹配 package.json

version

这是程序包锁定的程序包版本。这必须与中的内容匹配 package.json

lockfileVersion

整数版本,1从此文档的版本号开始,在生成this时使用了其语义package-lock.json

packageIntegrity

这是从中创建的子资源完整性package.jsonpackage.json不应进行任何预处理。子资源完整性字符串可由类似的模块生成 ssri

表示安装是在NODE_PRESERVE_SYMLINKS启用环境变量的情况下完成的 。安装程序应坚持使该属性的值与该环境变量匹配。

dependencies

程序包名称到依赖对象的映射。依赖项对象具有以下属性:version这是一个说明符,可唯一标识此程序包,并应可用于获取其新副本。

  • 捆绑的依赖关系:不管来源如何,这都是一个纯粹用于参考目的的版本号。
  • 注册表源:这是一个版本号。(例如,1.2.3
  • git源:这是一个具有已解决承诺的git说明符。(例如,git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e
  • http tarball来源:这是tarball的URL。(例如,[https://example.com/example-1.3.0.tgz](https://example.com/example-1.3.0.tgz)
  • 本地tarball来源:这是tarball的文件URL。(例如file:///opt/storage/example-1.3.0.tgz
  • 本地链接源:这是链接的文件URL。(例如file:libs/our-module
integrity

这是此资源的标准子资源完整性

  • 对于捆绑的依赖项,无论来源如何,均不包括在内。
  • 对于注册表源,这是integrity注册表提供的,或者如果未提供SHA1 shasum
  • 对于git源,这是我们从中克隆的特定提交哈希。
  • 对于远程tarball源,这是基于文件SHA512的完整性。
  • 对于本地tarball源:这是基于文件SHA512的完整性字段。
resolved
  • 对于捆绑的依赖项,无论来源如何,均不包括在内。
  • 对于注册表源,这是相对于注册表URL的压缩包的路径。如果tarball URL与注册表URL不在同一服务器上,则这是完整的URL。
bundled

如果为true,则为捆绑的依赖关系,并将由父模块安装。安装时,此模块将在提取阶段从父模块中提取,而不是作为单独的依赖项安装。

dev

如果为true,则此依赖项仅是顶层模块的开发依赖项,或者是一个传递性依赖项。对于既是顶层的开发依赖关系又是顶层的非开发依赖关系的传递依赖关系的依赖关系,这是错误的。

optional

如果为true,则此依赖项仅是顶层模块的可选依赖项,或者是一个传递性依赖项。对于既是顶层的可选依赖关系又是顶层的非可选依赖关系的传递性依赖关系的依赖关系,则为false。
即使所有可选依赖项都可以在当前平台上卸载,也应包括在内。

requires

这是模块名称到版本的映射。这是此模块所需的所有内容的列表,无论它将安装在何处。版本应通过正常匹配规则匹配我们dependencies或更高级别的依赖关系 。

dependencies

此依赖关系的依赖关系,与顶层完全相同。

作者

yenkos

发布于

2021-04-02

更新于

2021-04-02

许可协议

评论

评论基础模式加载中。如需完整体验请针对 disq.us | disquscdn.com | disqus.com 启用代理并 尝试完整 Disqus 模式 | 强制完整 Disqus 模式
    加载更多评论