js-libp2p integration into TypeScript projects is not straightforward not up to the general DX level that language community is accustomed to. The lack of stable bindings implies a considerable amount of fiddling due to most things being an Any type, or outdated.
As a result, the team developing a TypeScript project using js-libp2p tends to develop type declarations for the libp2p modules that they depend on, adding to the workload.
We want to make js-libp2p pleasurable and seamless to use with TypeScript projects.
TypeScript projects will be able to use libp2p out of the box without worrying about pulling in any types. 3rd party types do exist, but need to be updated there anytime an api change occurs with libp2p.
When we provide TypeScript bindings for all js-libp2p modules, libp2p will become a viable networking layer for TypeScript developers.
New TypeScript projects looking for a networking solution will not take into account libp2p, as a result of all the integration work needed.
The expected output is to have typing declarations to all js-libp2p modules.
There has been discussion around TypeScript declarations at libp2p/js-libp2p#208. The Polkadot team has created bindings for many of the libp2p modules, https://github.com/polkadot-js/ts/tree/master/types. The major issue is that these bindings have to get updated any time a change to the api is created. The hope is to move the bindings into their relevant modules, so that they ship and are updated with the JS code.
- The implementation should ensure that the TypeScript bindings are easy to maintain. As js-libp2p is pushing to have full jsdocs for all code, generating the bindings from the jsdocs is a potential option.
- CI should run a check on the bindings to verify they're up to date. This step should be allowed to fail to avoid blocking contributors on this step.
Protocol Labs, ETHBerlinZwei.