-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add flow type annotations. #51
Conversation
|
||
[include] | ||
|
||
[options] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vmx guessing that these .flowconfig files will be removed in your effort to add flow directly to aegir, correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't believe that would be possible given that flow uses .flowconfig to detect the root what needs to be type-checked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, is there no way for us to specify where the config file is located? Feels very suboptimal if we have to add this to every repository...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, is there no way for us to specify where the config file is located? Feels very suboptimal if we have to add this to every repository...
As far as I know it's still the case (at least there is no documented parameter to a flow command). Please note that it's not as much of an issue about specifying a config (.flowconfig
could be a blank file) but rather about not being able to specify a root from which to type-check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@victorbjelkholm I hope to have it go away. @garrensmith will have a look.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reading here, it doesn't seem like we can remove the flowconfig file. It should be a very simple file for each project. I don't think it would be to much of an issue having it in each repo. We could maybe look at having AEgir generate a generic .flowconfig file for a repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me! Thanks :)
Can we have a review from the captain as well? Ping @diasdavid
@victorbjelkholm, @vmx is leading this endeavor ipfs/js-ipfs#1260, I'll wait for his advice in what to do here. |
I think it would make sense to wait for multiformats/js-multihash#49 to be merged and then rework this PR to do the same thing. |
Closing this as we currently support Typescript typings. |
As dive into ipfs / libp2p code base I struggle to guess what are all the things passed around. Types as in flow (or typescript for that matter) simplify learning of how things are connected significantly. There for I decided to contribute type signatures to the code base as I digg through it.
What's up with all these .js.flow files ?
Unfortunately flow project has yet to come up with coherent story of how to provide type annotations for third party libraries. In my experience adding
.js.flow
files works best out of all options, that is because flow type checker when gives a precedent to/path/to/file.js.flow
over/path/to/file.js
which essentially provides a way to provide type annotations for non-flow typed package such that just using it as dependency will satisfy both type checker and run-time.It's far from ideal given that
.js
and.js.flow
files can get out of sync but then again unless you're open to adopt flow this is the best option IMO.