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

近日，IPFS官方博客宣布，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：

最后，在某些地方，我们先前返回了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项目路线图，其中包含按我们希望其着陆顺序排列的标题功能。

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

感谢阅读！

本文由老司机翻译，原文地址为

https://blog.ipfs.io/2021-05-11-js-ipfs-0-55/

在右下角留下你的赞吧