Flow type checker errors in node_modules/*

Question

I've initialized flow project with flow init in fresh https://github.com/davezuko/react-redux-starter-kit project.

When Flow does it check, it finds several errors in node_modules. Errors are happening in /* flow */ annotated library files.

It looks like this:

node_modules/editions/source/index.js:33
 33:    const {name, editions} = require(packagePath)
                                 ^^^^^^^^^^^^^^^^^^^^ The parameter passed to require() must be a literal string.

node_modules/fbjs/lib/Deferred.js.flow:60
 60:     Promise.prototype.done.apply(this._promise, arguments);
                           ^^^^ property `done`. Property not found in
474: declare class Promise<+R> {
     ^ Promise. See lib: /private/tmp/flow/flowlib_d34ebcf/core.js:474

node_modules/fbjs/lib/shallowEqual.js.flow:29
 29:     return x !== 0 || 1 / (x: $FlowIssue) === 1 / (y: $FlowIssue);
                               ^^^^^^^^^^ identifier `$FlowIssue`.     Could not resolve name

Should I make Flow ignoring those files? I assume it may affect type checking correctness.

Answer 1

Both fbjs and editions are written using Flow. They each have .flowconfig files with various configurations. All the errors that you are seeing are due to your .flowconfig being configured slightly differently.

The easiest fix is to modify your .flowconfig to support the things that edition and fbjs are using.

1. Adding module.ignore_non_literal_requires=true to the [options] section should fix the first error. By default Flow will error if you pass a variable to require(), since Flow wants to understand the dependency graph. This option relaxes this requirement.
2. Adding ./node_modules/fbjs/flow/lib to the [libs] section should fix the second error. fbjs uses a non-standard version of Promise, but it does ship with a library definition for that version of Promise.
3. Adding suppress_type=$FlowIssue to the [options] section should fix the third error. This option just aliases the any type to $FlowIssue. It makes it more clear when you're using any to suppress an error.

In the future, the Flow team imagines that Flow users will choose to ignore node_modules/ altogether and instead rely on library definitions from https://github.com/flowtype/flow-typed/, so we're investing in definitions and tooling around flow-typed. This will avoid the sort of situation that you're running into.