flow v0.57.x don't shows no errors if use `module.system.node.resolve_dirname=src`

[gin0606]

I need help!

flow don't show any errors, if write module.system.node.resolve_dirname=src in .flowconfig

https://github.com/gin0606/flow-v0.57.1-trouble

Please see this repository, that can see my trouble.

Thanks!

Maybe related to https://github.com/flowtype/flow-bin/issues/91 and https://github.com/facebook/flow/issues/5105

[apsavin]

Still an issue with 0.58.0

[kogai]

I'd encountered the same problem, and dug down into a code of the Flow, then I think that I found what the reason it caused.

First, in version 0.57 of Flow, the feature as described below added

New Features:
Flow will now only check the files in node_modules/ which are direct or transitive dependencies of the non-node_modules code.

Also, the document explains about setting module.system.node.resolve_dirname as below.

module.system.node.resolve_dirname (string)
By default, Flow will look in directories named node_modules for node modules. You can configure this behavior with this option.

In other words, adding a setting to resolve_dirname means that a directory added will not be checked as well as node_modules unless imported from the file where not in the directory set to resolve_dirname and not set to the ignore option.

As far as the document explained, I think this behavior may be the intended of the Flow team.
But it will confuse some users, including me.

My workaround is to import files where Flow check lazily, from files where Flow check immediately

For example, in case of @gin0606 https://github.com/gin0606/flow-v0.57.1-trouble, we will be able to force type checking by placing the file like below in the root directory of the repository.

// ./src/index.js
// @flow
import bar from 'foo/bar';

let num: number = 1;
let numerror: number = 'string';
let string: string = bar();

console.log(num);
console.log(numerror);
console.log(string);
+ 
+ export default () => {};

// In root of repository ./root.js
+ import fn from "./src"

But the workaround seems not absolutely ideally.
My personal opinion is that it should be checked lazily node_modules directory only.
Because some users use resolve_dirname option conjunction with resolve.modules option of the Webpack.

If we need PR to make such corrections, I will be honored to make it.

However, for us to find an ideal solution about this, I would like to hear the opinion of the Flow team on this Issue especially @gabelevi 's one (because he added such feature in https://github.com/facebook/flow/commit/385da8e95b3d7e759f8419b8b86216a9aa9f8f42).

[bradennapier]

I actually implemented a workaround for this problem. It doesn't keep the exact same behavior but you get your errors back in the case described by the OP:

Simply change:

module.system.node.resolve_dirname=src

to

module.system.node.resolve_dirname=./src

It will not give you the bubble effect but it will let you use your base directory for all imports

[apsavin]

Thanks @kogai !

For our project we've just replaced module.system.node.resolve_dirname=src with several module.name_mapper, like this:

module.name_mapper='^desktop/\(.*\)$' -> '<PROJECT_ROOT>/src/desktop/\1'

And it seems that it fixed the issue.

[bradennapier]

On the project I am using now the relative url definitely fixes the issue.

[ajhyndman]

I'd like to echo the question from @kogai.

We are using Flow in a fairly large project, with the module.system.node.resolve_dirname rule pointing to our local source code.

Maintaining a list of individual name_mapper rules is going to be quite unwieldy and error prone. Converting every import statement to a relative import will also be difficult at this stage, and seems likely to increase the fragility of our codebase.

It would be great to hear the flow team's thoughts on this issue, and investigate possible alternatives.

[qamil]

Experiencing the same issue. But here is the weird thing: on OSX it works perfectly fine. On our CI (Travis, Ubuntu 14.04.5 LTS) it fails to output any errors.
Unfortunately the workaround of a list of name_mapper rules doesn't work. Maybe a difference with others is that we run flow check with the --all flag.

[stasgavrylov]

@qamil I had the same issue just yesterday, and although I know that it probably won't help everyone, I made CI checking work by changing module.system.node.resolve_dirname=src to module.system.node.resolve_dirname=./src

[callumlocke]

Any idea why the ./ trick works? Thanks to @bradennapier I've now got this:

[options]
module.system.node.resolve_dirname=node_modules
module.system.node.resolve_dirname=./app

...and it works great – Flow skips checking non-depended files within node_modules, but it always checks everything in app, which is what I want.

But I'm concerned this might be an unsupported hack, that it might get 'fixed' in a future Flow version and stop working. Is the ./ trick an approved way to opt-out of the 0.57.0 new feature, or is there a better method that is sanctioned by the Flow team?

[alexeyraspopov]

I think you can find the answer here: https://github.com/facebook/flow/issues/5647

[JakubRimal]

@callumlocke It seems like it works for me as well (with Flow 0.66.0), thanks!

[callumlocke]

@alexeyraspopov I can't see an answer to my question there. Can you be more specific?

[alexeyraspopov]

@callumlocke, do not use resolve_dirname for your code. Use name_mapper instead.

[callumlocke]

@alexeyraspopov can you point to where a Flow team member has said this is the better course of action? Or some official docs saying this?

My app has a lot of subdirs. Using several name_mapper lines (one for each subdir under app) is more complex, and a bit harder to maintain (need to remember to update the flow config whenever our directory structure changes). So before doing that, I want something official.

[JakubRimal]

@alexeyraspopov you are right, usage of module.name_mapper is the correct solution. It's a pity that it is not clear from the official documentation especially when module.system.node.resolve_dirname was commonly used for aliases.

@callumlocke for every folder under src add the following line to [options] section of your .flowconfig file:

module.name_mapper='^my_folder/\(.*\)$' -> '<PROJECT_ROOT>/src/my_folder/\1'

BTW now I think this issue can be closed... :)

[alexeyraspopov]

can you point to where a Flow team member has said this is the better course of action? Or some official docs saying this?

This is why my issue exists. Docs need improvements to emphasize this part.

[JakubRimal]

@callumlocke I agree that it is harder to maintain but the official documentation (https://flow.org/en/docs/config/options/#toc-module-system-node-resolve-dirname-string) says that module.system.node.resolve_dirname should be used for specifying of node modules location. Using it for aliases of our modules was kind of hack I think.

[callumlocke]

@JakubRimal @alexeyraspopov OK, I have PR'd a docs update. Please go and upvote it if you agree: https://github.com/facebook/flow/pull/5850

[callumlocke]

This issue is also being tracked at https://github.com/yahoo/react-intl/issues/1086

[dgcoffman]

module.system.node.resolve_dirname should be used for specifying of node modules location. Using it for aliases of our modules was kind of hack I think.

Right, it's bad that this hack is the only sane way to make flow work as expected right now.

[TrySound]

Resolving modules from directory is a hack itself. It's not expected by browser or node.

[STRML]

And yet, it's intensely useful and I wouldn't do a project without it.

On Mar 5, 2018 11:59 PM, "Bogdan Chadkin" [e-mail] wrote:

Resolving modules from directory is a hack itself. It's not expected by
browser or node.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/facebook/flow/issues/5180#issuecomment-370673006, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABJFP7TolgMcBXkdOrWKLUfMRBXqmA9vks5tbiW-gaJpZM4QFbXC
.

[MaxInMoon]

Just a question to be sure to understand:

If I have 60 components in src/components/ like so:

src/
├── components/
│   ├── Button/
│   ├── Loader/
│   ├── RainMaker/
│   ├── .../

Do I have to write 60 name_mapper lines like:
module.name_mapper='^Button\/\(.*\)$' -> '<PROJECT_ROOT>/src/components/Button\1'

In order to import a component like:
import Button from 'Button';

??

It is possible to do like so?
import Button from 'components/Button'
?

Thanks in advance

[STRML]

Just one if you're doing components/. Yes, if you wanted to do all of them with no prefix, you'd have to write a mapper for every single directory. I wouldn't recommend that pattern anyway.

module.name_mapper='^components\/\(.*\)$' -> '<PROJECT_ROOT>/src/components/\1'

[leethree]

@stasgavrylov 's workaround (https://github.com/facebook/flow/issues/5180#issuecomment-344226227) works for us. But we would really like this issue to be fixed officially by Flow.

[crobinson42]

The flow config option module.system.node.resolve_dirname=src is still not documented as of version 0.77 - but the ./src solution is working.

[EddiG]

The module.system.node.resolve_dirname=./src doesn't work on 0.83.0

[vjpr]

module.system.node.resolve_dirname=./src works for me in 0.85.0. This is my scenario:

module.system.node.resolve_dirname=modules

 - foo
   - index.js
      // @flow 
      const a: string = 1

modules/foo/index.js was not getting type-checked.

Changing to module.system.node.resolve_dirname=./modules made it be type-checked.

---

In future, I will use require('modules/foo') for my aliases and use the name_mapper.

[yoavniran]

I just started encountering the same issue on flow 0.119.1
no errors are shown while there are several in the code. Changing a file will introduce some errors but the behavior is completely erratic

Using:
module.system.node.resolve_dirname=./src
instead of:
module.system.node.resolve_dirname=src

makes flow report every import for a file inside my project (under src) as unable to resolve.

Did anyone find a solution that doesnt include writing custom regex mapper for each folder in my src root?
Having to maintain a matching list of folders seems like a terrible way to go about keeping my code safe...