Flow: Circumventing @flow comments with an option in .flowconfig

Created on 7 Apr 2016  路  11Comments  路  Source: facebook/flow

I recently tweeted this to the flow Twitter account with the following question/request.

Is there a feature for .flowconfig to specify a glob of files to be type checked? This would allow people to avoid placing // @flow comments everywhere will still not type checking dependency code.

This would be especially useful for people with greenfield projects that want to use flow from the outset.

A concern risen in the Twitter thread was the complexity of nested .flowconfigs, one solution to this may be a .enableflow file which enables flow recursively for the current directory instead of requiring // @flow comments.

question

Most helpful comment

Again careful with that, it's not recommended right now.

All 11 comments

Any update on this?

Yes, any update on this? Requiring a @flow comment is why I still default to TypeScript for most projects. The TypeScript configuration story is better.

cc @thejameskyle

There is an option, it's all=true. It's currently undocumented because of the unintended side effects it can have in relation to having packages node_modules with/without that option on.

/cc @jeffmo

@thejameskyle Thank you! Much appreciated.

Again careful with that, it's not recommended right now.

Are there plans to make it a recommended option?

Not really, without an alternative file extension there's really nothing that resolves the issue. /cc @jeffmo

Is it possible to restrict the all option to, e.g., the src/ directory?

Noob here, but is there a reason it can't work like ESLint? Like having an exclude option and then just run for everything else. And maybe have some default excludes like dist or node_modules etc.

I think this is a duplicate of https://github.com/facebook/flow/issues/284. Let me know if I should reopen, though!

Given there have been three issues asking for this feature (#284, #1519, and #1634) are there any plans to incorporate such a feature? Also, I feel as if this issue has had more activity than #284 as well as providing a solution with all=true, perhaps this should be left open?

It seems like @jeffmo鈥檚 comment in #284 (https://github.com/facebook/flow/issues/284#issuecomment-155648150) is the only argument against this. As its almost been a year have circumstances changed? Also, if recursive .flowconfig files are difficult, why not introduce another file say .enableflow which would recursively enable flow? Or a .flowinclude file which acts as the inverse of a .gitignore.

Was this page helpful?
0 / 5 - 0 ratings