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

近日,分布式存储协议官方博客宣布,js-ipfs@0.55.0最终有了一套全新的TypeScript类型定义,这些定义完全是从头开始完全重写的。

js-IPFS 0.55.0改善了TypeScript类型定义
TypeScript类型定义已被彻底重写
以前0.51.0,我们附带捆绑的TypeScript类型定义,这些定义使用户能够通过智能感知来探索IPFS Core API。并使用它来确保它们正在调用存在的方法,但是对参数和返回类型进行了频繁标记,尽管这不会引起TypeScript编译错误,但实际上给您带来的类型安全性却很少。 问题的一部分是js-ipfs公开了许多TypeScript定义不附带的支持模块的返回类型。这意味着我们要么必须在这些模块中提供对TypeScript定义的PR支持,要么在js-ipfs容易出错的级别上输入其输入/输出,并且不能保证实际的基础代码。 我们查看了一下堆栈,并开始从最低级别开始添加TypeScript类型,这是一项艰巨的工作,其中约有250个拉取请求被打开、查看、合并和交付,这是此工作的一部分。
noImplicitAny
早些时候,我们决定启用noImplicitAny ,在我们的tsconfig.json文件中。这是一个严格的设置,当找不到任何变量的类型信息时,将导致错误。 这意味着必须在内部键入所有内容,这增加了交付此版本所必需的工作量,但是我们的内部代码现在更加安全,甚至在实现中出现一些错误和未处理的极端情况,因此强烈建议升级。
将来的证明
与我们支持的版本一致,js-ipfs@0.55.0已放弃了对Node.js <14的支持,这样一来,我们就可以支持最新和最好的功能,而不必承担任何麻烦。我们还切换到对顶层模块使用命名导出,而不是使用默认导出,因为这使它们更易于从ES模块中使用环境。这也意味着从JSDoc注释生成的类型定义更紧凑,必须跳过更少的圈以反映它们生成的代码。 从外部API的角度来看,这仅影响ipfs-http-client:

js-IPFS 0.55.0改善了TypeScript类型定义最后,在某些地方,我们先前返回了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项目路线图,其中包含按我们希望其着陆顺序排列的标题功能。js-IPFS 0.55.0改善了TypeScript类型定义

路线图中只标注了较大的功能,期望在路线图项目之间发布许多小的错误修正。 非常感谢所有能够发布此版本的人。

源自:星际联盟

免责声明:平台所发布文章仅代表作者个人观点,与链科天下无关。文章内的信息、意见等均仅供参考,并非作为或被视为实际投资建议。

(1135)

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注