5 Things You might be Interested in Your Flow Config

In ShopBack, we use FaceBook Flow as our static type checker in a new web application project. Flow is much lightweight than TypeScript and easier to learn for developer. Before we started to adopt Flow, we already knew the community is not stronger than TypeScript and if you face a problem that will be a bit hard to fix properly. So in this article, I would like to share common Q&A you probably will encounter when you adopt Flow.

Should I ignore node_module in my .flowconfig?

No. when you start to adopt flow in your existing project, you don’t need to ignore node_module. If you ignore it like that in .flowconfig:

[ignore]
.*/node_modules/.*

Flow check will blame about it’s unable to resolve dependencies like:

If you don’t ignore it already but still see abnormal check errors from node_modules, you can consider two solutions:

1. Do not ignore node_module and let flow to check the node_modules. But you can consider to ignore the specified packages like:

[ignore]
.*/node_modules/jsonlint/.*

2. Use untyped to make flow makes node_module un-typechecked but can still be require()‘d.

[untyped]
.*/node_modules/*

How to fix module resolve error?

Developer usually like a clean module resolve path, for example:

import something from 'utils/calculator'

instead of

import something from '../../../../../utils/calculator'

But if you use the favor one, flow check must show the error about it’s unable to resolve the modules. Don’t worry, module.name_mapper can solve this:

[options]
module.name_mapper='^utils\/\(.*\)$' -> '<PROJECT_ROOT>/src/utils/\1'
module.name_mapper='^components\/\(.*\)$' -> '<PROJECT_ROOT>/src/components/\1'
module.name_mapper='^containers\/\(.*\)$' -> '<PROJECT_ROOT>/src/containers/\1'

How to resolve a CSS/SCSS module?

When you try to import a CSS or SCSS file into a module, flow check must complain about it can not resolve the this module due to file extension issue:
“Required module not found”

So you have to tell flow that what extension should be resolved, for example:

[options]
module.file_ext=.scss

However, it’s still not enough due to Flow can not recognize the CSS or SCSS syntax, so one more configs you have to add:

[options]
module.file_ext=.scss
module.name_mapper.extension='scss' -> 'empty/object'

Unfortunately, after you configure above settings, Flow checks on all the JavaScript file will be ignored... so you have to add JavaScript file to another extension:

[options]
module.file_ext=.js
// Remember to add any file extension you need to check module.file_ext=.scss
module.name_mapper.extension='scss' -> 'empty/object'

Handle third party code

Sometimes, you may just cope a third code into your code base but you want those code won’t parsed or parsed but doesn’t preserve types. Again, it’s a little similar issue and it can be easy to solved by untyped. Following is official example:

[untyped]
.*/third_party/.*
.*/src/\(foo\|bar\)/.*
.*\.untype\.js

What's the difference between ignore and untyped?

[ignore] tell Flow DO NOT PARSE the specified files, default Flow will parse everything!! In most cases, You should not use this to ignore your code because that will cause checking error in somewhere that import/require this code.

[untyped] instead causes a file to be ignored by the type checker as if it had noflow in it, resolve modules as any type. If you don’t want Flow to do the type check on your code but still need it to be resolved, you are supposed to use untyped instead of ignore .