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.

Gyve

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.

Vaticinal

Should we just put all of node_modules in [declarations] now? #66488347 – Impropriate

Answer 2

I personally like to ignore everything under node_modules by doing this.

[ignore]
.*/node_modules/.*

I then use flow-typed to install or stub all imports https://github.com/flowtype/flow-typed

Iscariot

I'd advise against doing this. If an NPM package has first class Flow support, this will cause flow to ignore its typings. – Pathogen

Disagree, this is not a good solution since you'd be ignoring a package's flow definitions which might not exist yet in the flow-typed directory – Minimus

The problem with flow-typed is that you have to manually manage the sync between your flow-typed dir and your dependencies in package.json. I mean, it's not necessary, but for a clean project it's something you have to consider. – Zandrazandt

@RafaelVidaurre When I don't ignore node_modules in my .flowconfig I get thousands of flow errors and my computer starts to freak out trying to run flow on all of those files. However, I would love to get the flow types made by the authors of npm modules. How do you handle all of the extra errors given in the majority of modules that are do not use flow? – Patriotism

There's now [declarations], and it seems to work for .*/node_modules/.*, but I'm not sure if there's any downside to it, so I asked: #66488347 – Impropriate

Answer 3

You can ignore node_modules by adding below line in .flowconfig in the section [declarations]

<PROJECT_ROOT>/node_modules/.*

Refer below screenshot as well

Below is link of document reference https://flow.org/en/docs/config/declarations/

It also says

Often third-party libraries have broken type definitions or have type definitions only compatible with a certain version of Flow. In those cases it may be useful to use type information from the third-party libraries without typechecking their contents.

Martinic