js-IPFS 0.55.0改善了TypeScript類(lèi)型定義

近日，IPFS官方博客宣布，[email protected]最終有了一套全新的TypeScript類(lèi)型定義，這些定義完全是從頭開(kāi)始完全重寫(xiě)的。

TypeScript類(lèi)型定義已被徹底重寫(xiě)

以前0.51.0，我們附帶捆綁的TypeScript類(lèi)型定義，這些定義使用戶能夠通過(guò)智能感知來(lái)探索IPFS Core API。并使用它來(lái)確保它們正在調(diào)用存在的方法，但是對(duì)參數(shù)和返回類(lèi)型進(jìn)行了頻繁標(biāo)記，盡管這不會(huì)引起TypeScript編譯錯(cuò)誤，但實(shí)際上給您帶來(lái)的類(lèi)型安全性卻很少。問(wèn)題的一部分是js-ipfs公開(kāi)了許多TypeScript定義不附帶的支持模塊的返回類(lèi)型。這意味著我們要么必須在這些模塊中提供對(duì)TypeScript定義的PR支持，要么在js-ipfs容易出錯(cuò)的級(jí)別上輸入其輸入/輸出，并且不能保證實(shí)際的基礎(chǔ)代碼。我們查看了一下堆棧，并開(kāi)始從最低級(jí)別開(kāi)始添加TypeScript類(lèi)型，這是一項(xiàng)艱巨的工作，其中約有250個(gè)拉取請(qǐng)求被打開(kāi)、查看、合并和交付，這是此工作的一部分。

noImplicitAny

早些時(shí)候，我們決定啟用noImplicitAny ，在我們的tsconfig.json文件中。這是一個(gè)嚴(yán)格的設(shè)置，當(dāng)找不到任何變量的類(lèi)型信息時(shí)，將導(dǎo)致錯(cuò)誤。這意味著必須在內(nèi)部鍵入所有內(nèi)容，這增加了交付此版本所必需的工作量，但是我們的內(nèi)部代碼現(xiàn)在更加安全，甚至在實(shí)現(xiàn)中出現(xiàn)一些錯(cuò)誤和未處理的極端情況，因此強(qiáng)烈建議升級(jí)。

將來(lái)的證明

與我們支持的版本一致，[email protected]已放棄了對(duì)Node.js <14的支持，這樣一來(lái)，我們就可以支持最新和最好的功能，而不必承擔(dān)任何麻煩。

我們還切換到對(duì)頂層模塊使用命名導(dǎo)出，而不是使用默認(rèn)導(dǎo)出，因?yàn)檫@使它們更易于從ES模塊中使用環(huán)境。這也意味著從JSDoc注釋生成的類(lèi)型定義更緊湊，必須跳過(guò)更少的圈以反映它們生成的代碼。從外部API的角度來(lái)看，這僅影響ipfs-http-client：

最后，在某些地方，我們先前返回了bignumber.js的實(shí)例模塊，過(guò)去這是必需的，因?yàn)镴avaScript缺少任意精度的數(shù)字類(lèi)型。BigInt 在我們所有受支持的環(huán)境中已經(jīng)存在了一段時(shí)間，因此我們一直bignumber.js在取而代之的BigInt是Core API 。 

Upgrade升級(jí)指南

我們利用這次機(jī)會(huì)使實(shí)現(xiàn)與已發(fā)布的Core API Docs保持一致。在某些情況下，可接受的輸入類(lèi)型比為向后兼容所記錄的輸入類(lèi)型要寬，但是這種兼容性是以代碼復(fù)雜性和增加的維護(hù)為代價(jià)的，因此那些舊的代碼路徑已被刪除。如果您針對(duì)Core API文檔進(jìn)行了編碼，那么您應(yīng)該對(duì)此已有一定的心理預(yù)期。

新功能

支持身份哈希

正在進(jìn)行的重大變化

支持的最低Node.js版本為14現(xiàn)在，所有Core API方法都具有類(lèi)型，某些方法簽名已更改現(xiàn)在，http，grpc和ipfs客戶端模塊使用命名的導(dǎo)出 

接下來(lái)是什么

查看js-IPFS項(xiàng)目路線圖，其中包含按我們希望其著陸順序排列的標(biāo)題功能。

路線圖中只標(biāo)注了較大的功能，期望在路線圖項(xiàng)目之間發(fā)布許多小的錯(cuò)誤修正。非常感謝所有能夠發(fā)布此版本的人。

感謝閱讀！

本文由老司機(jī)翻譯，原文地址為

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

在右下角留下你的贊吧