3 ms·
A much more typical experience is to do those 2 steps, and then spend a bunch of time digging through github issues to find the right ignore/suppression incanta
by gcommer 9y ago
A much more typical experience is to do those 2 steps, and then spend a bunch of time digging through github issues to find the right ignore/suppression incantations to add to your .flowconfig so that your dependencies (including all their transitive deps...) don't break your typechecking. Admittedly this gets easier once you've done it before and know a few reference .flowconfigs to copy/paste like React[1] or babel[2], etc. But this shouldn't be necessary at all. It's been an open issue for 2 years [3].
Less important, but you also have to add /* @flow */ to the top of every single source file. Sure its handy sometimes for existing projects, but it makes little sense for new ones and has also been an issue for years[4].
[1]: https://github.com/facebook/react/blob/65b9ad94aaf62eb61b7b3888362c2e7c0b06697a/.flowconfig https://github.com/facebook/react/blob/65b9ad94aaf62eb61b7b3...
[2]: https://github.com/babel/babel/blob/634c750558e5ce149b879b66888d5ffd41865cab/.flowconfig https://github.com/babel/babel/blob/634c750558e5ce149b879b66...
[3]: https://github.com/facebook/flow/issues/869 https://github.com/facebook/flow/issues/869
[4]: https://github.com/facebook/flow/issues/284 https://github.com/facebook/flow/issues/284
- whatever_dude 9y agoThis has been my experience as well. I used to think configuring tsconfig was more work than I wanted, until I started using Flow in a project and had to babysit .flowconfig. It's hell and adding any dependency can break it in confusing ways.