Skip to content

Commit

Permalink
tighten scope
Browse files Browse the repository at this point in the history
  • Loading branch information
rvagg committed Mar 22, 2021
1 parent f0bc4c5 commit b47e177
Showing 1 changed file with 10 additions and 5 deletions.
15 changes: 10 additions & 5 deletions proposals/79-typescript-definitions.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,11 +19,16 @@ Remaining work to integrate the current set of js-ipfs dependencies into js-ipfs
Aside from completing the remaining js-ipfs integration work, the scope of this project includes some additional libraries that are not currently part of the js-ipfs dependency tree, including:

* Next-generation IPLD codec libraries (using the js-multiformats pattern)
* [js-multiformats legacy interface](https://github.com/multiformats/js-multiformats/issues/67)
* js-libp2p core types had a first iteration, but there are a few gaps that should be addressed, specially in the configuration, [as follow up](https://github.com/libp2p/js-libp2p/issues/830). There is also a general libp2p typescript [tracking](https://github.com/libp2p/js-libp2p/issues/659) with all the libp2p modules, but these do not seem high priority at the moment, as most users typically only interact with the core API.
* _TODO: what other non-archived, non-dormant project should we include here to achieve the above value & impact ideals?_

Project-specific decisions will be made regarding the depth of TypeScript definitional work. Projects with greater expected future usage should include full type checking in CI and will therefore require basic inline TypeScript annotations. Projects that are dependencies but are not expected to be actively maintained or developed further into the future may just include basic API type definitions so that dependents can make use of those.
* [js-multiformats legacy interface](https://github.com/multiformats/js-multiformats/issues/67) needs updating to match the newly exported js-ipfs/js-ipld types.
* [js-multiaddr](https://github.com/multiformats/js-multiaddr/pull/159) is mostly done, but needs to be a non-breaking change to land
* js-libp2p core types had a first iteration, but there are a few gaps that should be addressed, specially in the configuration, [as follow up](https://github.com/libp2p/js-libp2p/issues/830).
* _Scope:_ the priority for js-libp2p is in the generally exported API, so direct users of js-libp2p have types for that interface.
* _Out of scope for this project:_ there is also a general libp2p typescript [tracking](https://github.com/libp2p/js-libp2p/issues/659) with all the libp2p modules, but these do not appaer to be high priority at the moment, as most users typically only interact with the core API.

During execution of this project, where questions of scope arise that are not covered above, library-specific decisions will be made regarding the depth of TypeScript definitional work using the following criteria:
* Projects with greater expected future usage should include full type checking in CI and will therefore require basic inline TypeScript annotations.
* Projects that are dependencies but are not expected to be actively maintained or developed further into the future may just include basic API type definitions so that dependents can make use of those.
* Any work estimated to be consisting of more than 2 days for 1 FTE will be either scoped as a separate project (or bundled into another, existing project, collecting future work), or be brought back to [the PR for this proposal](https://github.com/protocol/web3-dev-team/pull/79) for further discussion of expansion of scope.

<!--
#### Background &amp; intent
Expand Down

0 comments on commit b47e177

Please sign in to comment.