Flow: Intermediate files without Flow pragma make it easy to accidentally circumvent Flow.

Created on 4 Sep 2018  ·  8Comments  ·  Source: facebook/flow

If I have a consumer and publisher of an interface with a@flow pragma, and an intermediate file without a pragma, Flow will ignore all typing and type interfaces as any.

This technically makes sense, but is a massive foot gun. When I searched multiple codebases it was a very prevalent problem. It mostly appeared when using superfluous index files (here's a repo version):

// foo/foo.js (provider)
// @flow
export default function foo(a: number, b: string) { }

// foo/index.js (author forgot Flow pragma)
export * from './foo';

// entry.js (consumer)
// @flow
import foo from './foo';
foo(false, {}); // Flow does not catch errors.

Instead of silently ignoring types, Flow could pass the type information along. Or, alternatively, warn if an intermediate file is missing an annotation that would let Flow do the expected thing.

Most helpful comment

Actually, it looks like we do have a flowlint for this. Try adding this to your .flowconfig:

[lints]
untyped-import=error

All 8 comments

https://github.com/gajus/eslint-plugin-flowtype has rules to enforce Flow annotations.

Yes, the lint rules can catch this (I put an example in my test repo), but that requires installing ESLint, installing the ESLint Flow rules, and then configuring the flowtype/require-valid-file-annotation rule correctly (it has a weird behaviour that does the wrong thing by default).

Flow doesn't aim to be the only tool you need for javascript development-- it's meant to be added to the JS toolchain. In particular, we try not to build in functionality that already exists in tools that don't require precise type information to work.

I recommend fixing the require-valid-file-annotation ESLint rule-- sounds like that would be very helpful to a lot of people!

That policy is news to me. When I was in Product Infrastructure there was always a big focus on the “pit of success”, and making sure developers naturally arrived at the correct solution.

Actually, it looks like we do have a flowlint for this. Try adding this to your .flowconfig:

[lints]
untyped-import=error

If that solution is sufficient, feel free to close the issue. If you already have that and it's not working I'll take a look to see what's up.

When I was in Product Infrastructure there was always a big focus on the “pit of success”, and making sure developers naturally arrived at the correct solution.

I don't think this really conflicts with flow not handling _all_ static analysis in Javascript. The JS tooling ecosystem is incredibly comprehensive, so trying to mimic all that behavior in one tool implemented by one team seems like a hard thing to justify.

Thanks for the follow up. I'll give the lint rule a shot.

Is the untyped-import linter supposed to check for .js.flow modules with the same name?

Was this page helpful?
0 / 5 - 0 ratings