Enable type-checker support in js-ipfs and js-libp2p

[Gozala]

Hi Folks,

Lately I have being trying to use js-ipfs in a project and got somewhat overwhelmed by amount of libraries at play, don’t get me wrong, I like the seperation of concerns this layered setup provides, it’s just incredibly hard to pin down what are the things being passed around and I’ve being following a rabbit hole for multiple days now. I also noticed the pattern across the stack where there are defined interfaces like transports and ipdl-resolvers, etc... and multiple implementations of them.

This got me thinking that it would be exteremly helpful if those interfaces were not just written out in markdown but were typed as flow (or typescript) interfaces than implementation could in fact declare that class / object implements it and type checker will make sure that is the case.

As I have being struggling to understand shapes of things being passed around (argument types, return types) I really started wishing those were tyoe annotated as that would have saved me so much time jumping across libraries to look things up. In fact I noticed that I had to look same things multiple times because as I kept going amount of info overflowed my mental capacity. That is yet another time where I wished type signatures were available as that would allowed my editor to just tell me what the interfaces is without following dependency chain and looking things up. In fact it got so difficult that I end up writing type signatures myself to save time redoing same lookups over and over.

Another controversial but still argument worth making is that there have type checker help make API’s clearer and lmby consequence easier for users. For instance I encountered a function that either takes protocol and buffer and returns string or takes protocol and string and returns buffer, it’s cool but consequently margin for error is higher + has runtime costs. Once you start using type system it navigates you towards less ambiguous API as concrete return types save you from type refinements down the line.

I also noticed multiple cases of polymorphic APIs where funtion needs to match over the type of argument and those checks are somewhat optimistic (as in no guarantee that argument is actually implements expected interface) that is another area where type checker like flow would greatly help. It provides a specific way to refine types and provides guarantees that with in the refined block value implements interface of that type it also ensures that no variant is being overlooked (meaning that each variant of argument type us handled).

[RangerMauve]

Typing would be useful. If this gains traction, I'd +1 for typescript, since flow is mostly just pushed by FB.
Maybe even having both type files where one is generated from the other.

[Gozala]

There is multiple ways one could go about adding type-checker support and each has different value proposition. I would personally advocate to go full on and just add flow to a toolchain as it would give you all the benefits at the cost of contributir workflow. I have experience with starting to use comments initially before going full on and from my experience no developer involved wanted to go back.

I understand that may not be ready to do that. So alternative could be to just add type annotations so that users of libraries will reap all the benefits and hopefully implementation would actually work as typed. I already submitted some pull requests to that end. Main issue with this approach is that type definitions and implementation start to get out off sync mostly because core contributors off the library don’t actually use type annotatins and type check can’t report any mismatches either.

[Gozala]

I’m also happy to lead this effort if there is a will to accept this.

[Gozala]

Typing would be useful. If this gains traction, I'd +1 for typescript, since flow is mostly just pushed by FB.

@RangerMauve It is true, but isn’t ts also just pushed by Microsoft ? I would prefer flow as type inference is far more superior and toolchain does not require full buy-inn.

Maybe even having both type files where one is generated from the other.

Sadly there is no such tool as far as I’m aware but if one of the typecheckers is used writing just tyoe signatures for the other should be viable and less prone to be out of sync

[Gozala]

I am also happy to provide specific explanation of why flow type checker type inference is superior and what does that actually provides as consequence if that is a conversation worth having.

[RangerMauve]

TS is used by more than just Microsoft, for example, Google's Angular team found it appealing enough to focus Angular 2+ on it, and I, personally, have seen more projects using TS than using flow.

[Gozala]

@RangerMauve Well if you're talking about users there are ton of users of flow as well at Mozilla we use it quite a bit and most of the projects around React ecosystem tend to use flow for the reasons you can guess. That being said you're probably right and more projects use TS but I wonder how much of that is due to TS being just an older project.

In terms of contributors to ts and flow projects they seemed to be mostly ms and facebook.

[RangerMauve]

This is why I would suggest supporting both, because otherwise there will be a constant stream of people arguing over which type system should be integrated with or not.

[Gozala]

Anyway here is a small list of objective reasons why I think flow is a better choice:

1. Flow type checker is nothing but a type checker, meaning it just type checks. Transpiling flow typed code into valid JS is done by other means often using babel and there is far more flexibility in terms of what you want output be than what you get with TS where tool does type checking transpiling and more, don't get me wrong it has configuration options but I've run into limitations that are a lot easier to overcome with babel.
2. I would not recommend doing this, but flow has an option to be typed via comments meaning that you have an option not to use any compilation at all.
3. Flow provides nominal typing along with structural typing via opaque type aliases which make a huge difference for performance critical code paths. Whenever you want to represent certain via string or Buffer or number and don't pay boxing costs but reap all the benefits of typing opaque type aliases give you type safety at 0 runtime cost.
4. Flow has type variance and ts does not, that allows flow type checker catch whole class of type errors that ts just cant.
5. Flow type inference is far more sophisticated. Easiest way to spot that is to say have a generic function / class that does not refer to it's type parameter. In flow that type will be inferred from the further usage while TS just treats it as {} that often a very bad assumption often forcing you to manually entype that parameter is any which essentially disables any kind of type checks for it. This is kind of boils down to flow having existential type and TS not having it, also notice that is fundamental difference between approach each type checker takes, or to put it differently it would require fundamental rewrite TS to fix that.
6. Flow provides $Call utility type that provides you essentially a way to extend type system in arbitrary ways as long as you can express that in form of function type signature.

[Gozala]

To be absolutely clear I'm happy to do the work necessary for flow integration. As of TS support, I think it would be great and someone should do it, it's just I can not contribute to that effort as it does not help me with my project. I hope you understand.

[Gozala]

Here is a list of PRs I'have submitted yesterday, before @victorbjelkholm asked me to open this issue:

• Add flow type signatures. libp2p/js-peer-info#62
• Add flow type signatures. libp2p/js-peer-id#75
• Add flow type annotations. multiformats/js-multiaddr#51

[Gozala]

Copying conversation from that happend over at libp2p/js-peer-info#62 (comment) with @dryajov as discussing it here makes more sense:

Is there anyway of distributing the typings as a separate package (similar to typescript @type/), so that we don't clutter this package with language specific types?

@dryajov there is flow-typed but sadly it's not nearly as good as in typescript and most flow users don't seem to use it for that reason. It is also that there is advantage of having type definitions with implementations as that gives some initiative to library contributors to keep them in sync otherwise they just don't match up (at least that is a big issue with flow-typed) type defs.

[Gozala]

So here is the list of options in which flow types could be added to the ipfs libraries:

1. Go full on with flow type checker.

Pros

• Type signatures will be guaranteed to be in sync with implementation.
• Implementations will be able to take advantages of type checker.
• Integration tools could type check pulls to make sure type safety.
• Libraries that implementing interface will be verified to do so by type checker.
• Users will just get types and guarantees without any extra work.

Cons

• Contributors would need to use flow type checker.
• Contributors will have to transpile flow typed code into JS.

2. Comment Types

Same list of pros / cons as above, except you'd trade need for transpilation with a lengthy comments blocks inline (usually makes it column width 80 a huge challenge).

3. Write file.js.flow along the side of implementation.

Pros

• Some libraries could take advantage of type checker. Kind of allow you to gradually explore options 1 and 2.
• Users will just get types and guarantees without any extra work.
• Provides some initiative to contributors to keep interface and implementations in in sync.

Cons

• No guarantee that implementation actually complies with type definition.
• Interfaces and implementations can get out of sync unless contributors are disciplined, in other words no tools won't be able to help you.

4. Add ipfs to flow-typed

I personally found that wrapping untyped library in another that just adds types is far more manageable than going through flow-typed as it reduces tool overhead and coordination with flow-typed maintainers.

Pros

• Users of ipfs could use flow-typed tool to get some type information.

Cons

• No guarantee that implementation actually complies with type definition.
• Users need to use additional tool in form of flow-typed
• Implementation and types are likely to get out of sync as contributors aren't even exposed to type defs.
• Keeping implementation and types in sync add's more steps to the workflow. Updating separate package, submitting a pull request etc..
• Sharing across libraries is somewhat broken, which is going to be quite painful due to number of libraries at play.

[Gozala]

Update

After doing some more exploration I realized that without type information for pull-streams utility of having type annotations in ipfs libs will be fairly limited. So I started doing flow-typed annotations for pull-streams which as it turns out has a very very very generic API since it takes 1 or 0 Source stream, arbitrary number of Through streams and 1 or 0 Sink stream and depending on combination returns either void, Sink, Through or Source and in order for type checker to be useful types need to flow through. Short version you can entype this to some degree (pull that takes up to 8 args) in flow and get a meaningful error messsages (sadly in the sea of useless output):

But in order this to work type checker needs support for existential types and type variance as described in the prior comment typescript has neither and there for it would not be able to handle type mismatches like this:

Note that transform on line 10 ends up being generic specifically it's type is <x, a> (Source<x, a>) => Source<x, a> regardless of what x and a types are. There for on line 11 error is reported as a is number due to pull.count(5) which missmatches expected string by pull.concat(). On the other hand there is no error on line 12 because because types align.

Typescript here would treated both x and a types in transform as {} and reporting errors in both instances line 11 an 12. Alternatively you could choose to use any type there, but it would not report errors neither on line 11 or 12.

I just wanted to put this out here to make it clear why I'm pushing for flow over ts. Please also note that pull-stream has quite exotic API but this issue occurs in not so exotic cases, essentially any time you return generic function who's type parameters are refined by it's usage later.

Edit: Changed second example to make my explanation somewhat more clear.

[daviddias]

Woa, tons of work and exploration here, thank you so much @Gozala 🙌🏽

This got me thinking that it would be exteremly helpful if those interfaces were not just written out in markdown but were typed as flow (or typescript) interfaces than implementation could in fact declare that class / object implements it and type checker will make sure that is the case.

💯 and also compliance tests to ensure that behavior is correct.

We have had in the past experimented with transpilation steps to support old ES5 browsers and after a while no one could bare to debug transpiled code all the way. The situation was especially bad since we have the code super modular and sometimes making a change requires you to to npm link 5 or 6 modules and so with transpilation, you would have to npm link everything and then transpile for every change. It was super painful to develop.

I saw your suggestion to add 3. Write file.js.flow along the side of implementation. and followed up on one of your PRs libp2p/js-peer-id#75 (comment).

Isn't there a way to check the type annotations on CI so that only well annotated code gets merged? This way the contributors would still be able to tinker with the code in plain JS and learn flow or get support to update the annotations just during the PR process. This would also avoid all the transpilation steps.

Adding the flow type annotations would also make doc generation way simpler. 10x💯 for that 👌🏽

[Gozala]

Woa, tons of work and exploration here, thank you so much @Gozala 🙌🏽

Here is even more not 💯 there yet but almost. Also I could use some feedback on whether my interpretation of APIs are correct. I did add bunch of // TODO: comments where I'm clearly confused. https://github.com/Gozala/ipfs-drive/tree/master/flow-typed/npm

We have had in the past experimented with transpilation steps to support old ES5 browsers and after a while no one could bare to debug transpiled code all the way.

It's unfortunate you had a bad experience with that. It could be that things have improved since, at least I don't struggle given that source-maps essentially allow me deal with code I've written.

The situation was especially bad since we have the code super modular and sometimes making a change requires you to to npm link 5 or 6 modules and so with transpilation, you would have to npm link everything and then transpile for every change. It was super painful to develop.

I'm not sure what setup did you use, but you can link as many modules as you like and compile only module you're making changes to. You don't need to build complete bundle. You could also have a watcher running that does compiling on changes.

Here is my usual setup: https://github.com/Gozala/router.flow/blob/master/package.json#L40
I usually compile all modules from ./src into ./lib such that each file get inlined source maps and a companion .js.flow file next to it. That way node just loads stuff from ./lib dirs of packages and type checker uses ./lib/*.js.flow companions for type checking. This way linked dependencies don't really affect my workflow. Sure if you do edits across linked packages you'd want to compile those changes, but I usually do npm start in repo's I'm working on and that just usually keeps me mostly out of the way.

Isn't there a way to check the type annotations on CI so that only well annotated code gets merged?

Sure, I usually run type checker on CI to catch any errors in the contrib pulls that I might overlook. But then again flow will type check annotated files, there is no way to tell it that file.js should be type compatible with file.js.flow. It's not really flow's issue it's just type checker won't have enough information to do a proper inference.

This way the contributors would still be able to tinker with the code in plain JS and learn flow or get support to update the annotations just during the PR process. This would also avoid all the transpilation steps.

I think you're trying to achieve two different goals, and I'll provide my input on each one separately:

1. Defer type annotations until PR is submitted.

I mean it's entirely possible to defer dealing with type-checker it's matter of just not running it locally. In fact I have being getting contributions from people who did not even installed one & once CI reported errors they went I fixed them without installing type-checker.

Please note that type-checking code is somewhat independent of transpiling (at least with flow). Now that being said, I don't think deferred use of type-checker is a good idea though. In fact that can make a terrible experience, it's a lot easier to deal types as you work because it forces you to stay checked, small mismatches have better error messages etc... Amount of errors one would get otherwise can be quite an overwhelming.

Another thing is that type-checker also guides you towards better interface design mostly because issues become apparent even before you get to implement. In fact many (including myself) tend to write out interfaces before doing any implementation work, you can sketch out API even try it out before you get to implement it.

2. Avoid compiler toolchain

I think only option where one could take full advantage of type-checker and avoid adding compilers into toolchain would be through flow comments as described above. In fact some editors (vscode does and I think atom as well) even syntax highlight and treats those comment blocks as if they were just code. I also noticed that some of the ipfs packages were using this already. You could possibly take it step further and define interfaces in separate files those will have only types so won't even load at runtime.

I think over time you'll probably be inclined to just switch to non commented options with transipiling, but this might be a least intrusive way to start. I would still recommend trying transpiler setup in one or two packages and see how it works out.

One thing I'm unsure with this route is how module imports going to work out, flow use native JS module syntax. I think there is some form of require support as well but I'm almost certain there will be limitations.

[daviddias]

It could be that things have improved since, at least I don't struggle given that source-maps essentially allow me deal with code I've written.

Given that js-ipfs and js-libp2p are designed to work both in Node.js and in the Browser, I take that you are suggesting that we always use node-inspector with all of our debugging so that we can get Source Maps for Node.js.

This is not necessarily a bad thing, just one that we have to handle with docs on the README on how to debug one of these modules. It happened in the past, when we did the transpilation madness, that contributors kept getting lost while trying to fix issues.

I'm not sure what setup did you use, but you can link as many modules as you like and compile only module you're making changes to. You don't need to build complete bundle. You could also have a watcher running that does compiling on changes.

Simple npm link. If you have 1 or more dependencies that requires the code to be transpiled in order for other modules to use it, then you have to make sure they get build after each change. So the process looked a bit like:

1. git clone js-ipfs
2. git clone all the other deps
3. change one of the inner deps
4. npm run build
5. npm link
6. go back to js-ipfs
7. npm link <that module name>
8. test
9. go back to 3 if it still didn't fix it

👍🏽 for better tooling such a watcher. We are getting a full working group on Team Dev Enablement, @victorbjelkholm has been structuring the goals for this quarter and might have some ideas on how to get these tools out the door faster :)

re: 1. Defer type annotations until PR is submitted. VS 2. Avoid compiler toolchain

"I think over time you'll probably be inclined to just switch to non commented options with transipiling, but this might be a least intrusive way to start."

I do feel that is going to happen too. I just want to make sure that the upgrade path is smooth and that we get to level up our way to dev without adding major obstacles that will disincourage contribution and participation on code reviews.

I think there is some form of require support as well but I'm almost certain there will be limitations.

John Dalton created std/esm to add support to ES Modules to Node.js, we explored it also here #951. It is not necessarily fully done but good enough to enable us to move forward, I think.

[Gozala]

Given that js-ipfs and js-libp2p are designed to work both in Node.js and in the Browser, I take that you are suggesting that we always use node-inspector with all of our debugging so that we can get Source Maps for Node.js which fixes makes stack report correct paths and line numbers. I mostly use vscode which happens to just work as well.

I didn’t imply that. There is node source maps support package (can’t remember name, on the 📱right now)

[Gozala]

Simple npm link. If you have 1 or more dependencies that requires the code to be transpiled in order for other modules to use it, then you have to make sure they get build after each change. So the process looked a bit like:

So workflow could be simpler even without wathcher. Just link once whatever you need to change (I assume that’s already a case) after changes run build in that package. Note that you don’t need to relink or rebuild package it was linked into (unless exposed API interface changed in incomplete way - major version bump in semver).

[daviddias]

Apologies for the delay in following up on this one.

I believe we have different experiences using these tools and there are clear learnings that have to happen from both parts. In order to avoid investing to much time in painting this bikeshed, I have a more pragmatic proposal.

Let's use follow for multiformats/js-* repos and ipld/js-cid and learn from that effort together. This test will challenge and get us all on the same page about some things, namely:

• Our understanding of how the pipeline should work
• The benefits of using a Type system (I believe we here all agree it is going to be better)
• The amount of custom tooling we need to build in order to support the modular development in IPFS land
• How to not increase the barrier of contribution

I expect that we it we will also learn how to dev faster (debug faster) and have always up to date docs.

The repos to upgrade are:

• js-multihash - Add flow type annotations. multiformats/js-multihash#47
• Add flow type annotations. multiformats/js-multiaddr#51
• https://github.com/multiformats/js-multihashing
• https://github.com/multiformats/js-multibase
• https://github.com/multiformats/js-multistream-select
• https://github.com/multiformats/js-multihashing-async
• https://github.com/multiformats/js-multicodec
• https://github.com/ipld/js-cid (needs almost all the above)

@Gozala I'll assume that you are still willing to take the lead on this endeavour. Pinging @vmx, @hacdias, @victorbjelkholm, @lidel, @olizilla and @alanshaw as reviewers. I believe everyone is interested on this :)

[vmx]

@Gozala I'd like to see js-cid being worked on as I'm especially interested in combining flow types with JSDoc.

[alanshaw]

I'm not a flow or typescript user. I've never used flow but I have worked on typescript projects in the past and got a bit bogged down with annotations and I felt like it hindered my productivity.

I found that annotations can get really tricky unless you only use them for the simple cases. Good type annotations should handle the tricky bits, but in my experience this means quite a significant investment in time to get right.

I could put that down to my newness to typescript but that aside, I personally don't find joy in authoring the tricky bits - I wouldn't, for example, relish the idea of authoring type annotations for pull streams.

I don't dispute that having type annotations would help some developers who use IPFS JS libs. I'm raising a concern that if we add annotations to the projects we're enforcing the overhead of learning and using flow type annotations on all current and future IPFS devs and contributors. It's something we'll have to maintain and use forever and it might deter contributions from the community.

I'm sad to hear that flow-typed is not so much used. I think the trade off of the types becoming out of sync with the code base is better than forcing people who don't care about flow to have to author flow type annotations.

[Gozala]

@alanshaw thanks for commenting on this issue, I think it's important tea hear arguments form both sides of the argument. I am also sorry to hear you had bad experience with typescript projects in the past, while I do realize no words could counter that experience, if you let me and keep an open mind I'd try to pursue to give it another chance.

Here some of my comments inline below:

I found that annotations can get really tricky unless you only use them for the simple cases. Good type annotations should handle the tricky bits, but in my experience this means quite a significant investment in time to get right.

You are absolutely correct that type annotations can be of arbitrary complexity starting with obvious and simple and picking levels of absurd, where understanding code is actually easier than understanding those type annotations. But I would argue it's not inherent to usage of flow or ts, like any tool they could be misused and abused. More on that below

I could put that down to my newness to typescript but that aside, I personally don't find joy in authoring the tricky bits - I wouldn't, for example, relish the idea of authoring type annotations for pull streams.

That is a perfect example actually, as I mentioned earlier type system tends to guide you towards a simpler API design, what I meant by that is if you end up designing an API like pull-streams you'll quickly realize that having same function entry with many different input combinations and returning many different kind of results is painful (for reasons you mentioned), so usually you face a choice of either making dead simple API choice (have a separate function for separate input / output combo), make your type annotations complex, or just bail from type safety (both ts and flow allow that but I'll cover that a bit later). But to be fare it's not really type annotations there to blame but rather an API choice than needlessly mixes different procedures into single one, in practice it does 4 different things:

1. Connects source to sink.
2. Creates source by connecting source to through.
3. Creates new sink by connecting through to sink.
4. Creates new through by connecting throughs.

I mean no offence to the pull-streams library but having four distinct functions would make reading code using pull-streams a lot easier. And if that was the case type signatures would have being pretty trivial as well.

Now on the relaxing type guarantees bit. Both ts and flow allow you to choose how much safety you'd like to get from the type system & make your choices accordingly. For instance for the pull-streams I really wanted to get no runtime error guarantee from flow which is why end up encoding all the combination of arguments it can take (well up to 9 arguments). So that if I try to say provide two sinks instead of sink & source I get type checker tell me that. I also wanted to make sure that if I have through from a -> b it could only connect to sink that handles b or through that is from b -> c or to source of a. It certainly possible to reduce amount of errors you're willing to catch at compile time at the expense of handling them at runtime, whether that's a good trade-off it really depends from case by case. Although in my experience you could you could avoid such trade-offs simply by not overloading an API.

I don't dispute that having type annotations would help some developers who use IPFS JS libs. I'm raising a concern that if we add annotations to the projects we're enforcing the overhead of learning and using flow type annotations on all current and future IPFS devs and contributors. It's something we'll have to maintain and use forever and it might deter contributions from the community.

That is entirely a valid point that it would require some degree of type system understanding for non trivial changes (by which I mean extending public API), but I don't necessarily agree in regards to changes that keep public API intact, given that there type annotations are purely optional and fully inferred, I also had contributors that knew nothing about flow or cared to install it successfully submitting changes, (sometimes changes required reword as flow in CI caught subtle issues, but I think that's a good thing).

Where I do disagree is though whether it is a good thing or not. I think you're viewing it purely in making usage of ipfs easier, while I view it as it would make it so much easier for people to contribute and making changes without fear. I am hesitant to state it as a fact but from my personal experience and experience of others I worked with static types do help make large projects more maintainable as you don't have to have a clear picture of the whole system, types provide you necessary context.

I'm sad to hear that flow-typed is not so much used. I think the trade off of the types becoming out of sync with the code base is better than forcing people who don't care about flow to have to author flow type annotations.

If the goal is to just make ipfs more accessible to it's users, I actually agree. Forcing everyone to use tool that they wouldn't otherwise use just to make ipfs more usable for few using does not seem like a right trade-off and flow-typed (however good or bad it might be) would make more sense.

That being said I'd argue that ipfs contributors could take a huge advantage by adopting a type-checker given the size of the project and layers involved. It is also worth considering that bunch of libraries interface-* already do define interfaces just in plain English and at least now are ambiguous at places, I think encoding them in types would clear that ambiguity.

I think what is being proposed by @diasdavid is to take small subset of libraries and try type-checker on those, that way we could actually learn all about pros & cons it provides and draw informed conclusions from there. Without this it's just speculation. Unless of course there is general agreement that there adding types is just for sake of ipfs users rather than contributors.

[Gozala]

Apologies for the delay in following up on this one.

I believe we have different experiences using these tools and there are clear learnings that have to happen from both parts. In order to avoid investing to much time in painting this bikeshed, I have a more pragmatic proposal.

Let's use follow for multiformats/js-* repos and ipld/js-cid and learn from that effort together. This test will challenge and get us all on the same page about some things, namely:

👍 I can't agree more! As mentioned earlier there is no way to draw informed conclusion without trying and learning from that.

Our understanding of how the pipeline should work
The benefits of using a Type system (I believe we here all agree it is going to be better)
The amount of custom tooling we need to build in order to support the modular development in IPFS land
How to not increase the barrier of contribution

I expect that we it we will also learn how to dev faster (debug faster) and have always up to date docs.

The repos to upgrade are:

https://github.com/multiformats/js-multihash
multiformats/js-multiaddr#51
https://github.com/multiformats/js-multihashing
https://github.com/multiformats/js-multibase
https://github.com/multiformats/js-multistream-select
https://github.com/multiformats/js-multihashing-async
https://github.com/multiformats/js-multicodec
https://github.com/ipld/js-cid (needs almost all the above)

@Gozala I'll assume that you are still willing to take the lead on this endeavour. Pinging @vmx, @hacdias, @victorbjelkholm, @lidel, @olizilla and @alanshaw as reviewers. I believe everyone is interested on this :)

I am not sure how far I'll be able to get this (due to time constraints) but I'm definitely eager to lead this effort till conclusions can be drawn on it's merits.

[Gozala]

@Gozala I'd like to see js-cid being worked on as I'm especially interested in combining flow types with JSDoc.

While it's entirely possible to start from there, in my experience it's more productive to start from the leaf dependencies, so maybe it would make sense to start from one that has no or least dependencies ?

[gozes]

any plans for typescript support as well?

[vmx]

@gozes Currently this effort is focusing exclusively on Flow. There are no plans for TypeScript support at the moment.

[achingbrain]

Closing as this was done via JSDoc types.