js-IPFS 0.55.0改善了TypeScript类型定义

我们很高兴地宣布,[email protected]最终有了一套全新的TypeScript类型定义,这些定义完全是从头开始完全重写的。

我们很高兴地宣布,[email protected]最终有了一套全新的TypeScript类型定义,这些定义完全是从头开始完全重写的。

250.png

TypeScript类型定义已被彻底重写

以前0.51.0,我们附带捆绑的TypeScript类型定义,这些定义使用户能够通过智能感知来探索 Core API。并使用它来确保它们正在调用存在的方法,但是对参数和返回类型进行了频繁标记,尽管这不会引起TypeScript编译错误,但实际上给您带来的类型安全性却很少。

问题的一部分是js-ipfs公开了许多TypeScript定义不附带的支持模块的返回类型。这意味着我们要么必须在这些模块中提供对TypeScript定义的PR支持,要么在js-ipfs容易出错的级别上输入其输入/输出,并且不能保证实际的基础代码。

我们查看了一下堆栈,并开始从最低级别开始添加TypeScript类型,这是一项艰巨的工作,其中约有250个拉取请求被打开、查看、合并和交付,这是此工作的一部分。

I noImplicitAny

早些时候,我们决定启用noImplicitAny ,在我们的tsconfig.json文件中。这是一个严格的设置,当找不到任何变量的类型信息时,将导致错误。

这意味着必须在内部键入所有内容,这增加了交付此版本所必需的工作量,但是我们的内部代码现在更加安全,甚至在实现中出现一些错误和未处理的极端情况,因此强烈建议升级。

251.jpg

将来的证明

与我们支持的版本一致,[email protected]已放弃了对Node.js <14的支持,这样一来,我们就可以支持最新和最好的功能,而不必承担任何麻烦。

我们还切换到对顶层模块使用命名导出,而不是使用默认导出,因为这使它们更易于从ES模块中使用环境。这也意味着从JSDoc注释生成的类型定义更紧凑,必须跳过更少的圈以反映它们生成的代码。

从外部API的角度来看,这仅影响ipfs-http-client:

252.jpg

最后,在某些地方,我们先前返回了bignumber.js的实例模块,过去这是必需的,因为JavaScript缺少任意精度的数字类型。BigInt 在我们所有受支持的环境中已经存在了一段时间,因此我们一直bignumber.js在取而代之的BigInt是Core API 。

Upgrade升级指南

我们利用这次机会使实现与已发布的Core API Docs保持一致。在某些情况下,可接受的输入类型比为向后兼容所记录的输入类型要宽,但是这种兼容性是以代码复杂性和增加的维护为代价的,因此那些旧的代码路径已被删除。

如果您针对Core API文档进行了编码,那么您应该对此已有一定的心理预期。

新功能

支持身份哈希

正在进行的重大变化

支持的最低Node.js版本为14

现在,所有Core API方法都具有类型,某些方法签名已更改

现在,http,grpc和ipfs客户端模块使用命名的导出

接下来是什么

查看js-IPFS项目路线图,其中包含按我们希望其着陆顺序排列的标题功能。

253.jpg

路线图中只标注了较大的功能,期望在路线图项目之间发布许多小的错误修正。

非常感谢所有能够发布此版本的人。

了解更多IPFS和Filecoin资讯的,联系时空云运营专员(WX:skyyoung0511)或者时空云官网:

  • 发表于 2021-05-28 16:26
  • 阅读 ( 486 )
  • 学分 ( 1 )
  • 分类:IPFS

0 条评论

请先 登录 后评论
时空云科技
时空云科技

运营专员

58 篇文章, 3 学分