Skip to content

Conversation

@HerringtonDarkholme
Copy link
Member

@HerringtonDarkholme HerringtonDarkholme commented Dec 26, 2016

This is an experiment striving to fix #4410. The improvement is based on CLI tool. The following command is used to inspect source.

flow coverage $TARGET.js --json | jq '.expressions .uncovered_locs[] .start .line'

Which prints out all the line number of potential unsound any type. Only files under src/compiler/codegen/ are checked.

To my consternation, we have a lot of implictAny in code base, (and I have no idea why). Fixing these any needs some weird typing and dependency on how flow works (in my conjecture).

While I really appreciate @thejameskyle 's suggestion, I'm afraid maybe our team's capability does not match Flow's type system.

As the title indicates, this pull request is experimental, feel free to close it.

@yyx990803
Copy link
Member

Thanks! The primary reason for the use of anys is usually because the original code was written in plain ES2015 without typing in mind. The flow types were later added on. In many cases, we can make assumptions about certain type scenarios based on code logic, but such logic cannot be easily inferred by Flow.

I don't think it's possible or particularly important to have full type coverage, since the whole point of Flow is gradual typing. The goal of introducing Flow in the codebase is to leverage it when we can.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants