It only works before save

[rico345100]

As title said, it works but only before save.

For example, if I access something non exists property in specific object type, flow gives me error like this:

[flow] Cannot get user.wallet.a because property a is missing in UserEntityWallet [1]. (References: [1])

However when I save the file, it just changed to this:

[flow coverage] uncovered code

It's really annoying because I save the file a lot. Here's my flow config settings:

[ignore]
.*/dist/.*
.*/node_modules/jsonlint/.*
.*/node_modules/rc-util/.*
.*/node_modules/react-apollo/node_modules/.*

[include]

[libs]
./src/global.js
flow-typed

[options]
esproposal.decorators=ignore
module.name_mapper='^.*\.css$' -> 'css-module-flow'
module.name_mapper='^.*\.scss$' -> 'css-module-flow'
module.name_mapper='^.*\.less$' -> 'css-module-flow'
module.name_mapper='^components\(.*\)$' -> '<PROJECT_ROOT>/src/components/\1'
module.name_mapper='^containers\(.*\)$' -> '<PROJECT_ROOT>/src/containers/\1'
module.name_mapper='^types\(.*\)$' -> '<PROJECT_ROOT>/src/types/\1'
module.name_mapper='^helpers\(.*\)$' -> '<PROJECT_ROOT>/src/helpers/\1'
module.system=haste
module.system.node.resolve_dirname=node_modules
module.system.node.resolve_dirname=src


[lints]

And here's the version I'm using:

• Node@8.12.0
• Flow@0.85.0
• flow-for-vscode@0.8.5

[ArmorDarks]

Probably related to the #286 or #278

[bradennapier]

this is caused by an error which ahs come back into play

module.system.node.resolve_dirname=node_modules
module.system.node.resolve_dirname=src

remove those and it will work

facebook/flow#5180 see this issue from way back - its been working for months now but started again.

[rico345100]

@bradennapier Thanks. You are right, now I get bunch of errors correctly! However if I just remove those lines, I have errors in node_modules, and can't import modules with absolute path :(

[bradennapier]

It actually appears to be an issue with vscode flow not flow itself FYI. The errors still show up just fine when using flow from the cli. Figure thats why you posted here but just making sure its mentioned :-D

My guess would be it has to do with engineer(s) not knowing how people use this property. As far as I can tell the problem generally happens when you are in the modules folder you specify.

In my case I use

module.system.node.resolve_dirname=shared
module.system.node.resolve_dirname=node_modules

When I have the following file in the shared folder anywhere I get no errors:

If I move this file anywhere outside of the shared folder, however:

I did notice in the /tmp/flow log that I have an error

[2018-11-15 20:36:29.499] Parsing
[2018-11-15 20:36:29.589] Re-resolving directly dependent files
[2018-11-15 20:36:29.589] Recalculating dependency graph
[2018-11-15 20:36:29.614] Merge prep
[2018-11-15 20:36:29.614] to_merge: Focused: 1, Dependents: 0, Dependencies: 0
[2018-11-15 20:36:29.614] Calculating dependencies
[2018-11-15 20:36:29.614] Merging
[2018-11-15 20:36:29.657] sending (2 errors) and (warnings from 0 files) to 1 subscribed clients (of 1 total)
[2018-11-15 20:36:29.657] Merge skipped 0 of 1 modules
[2018-11-15 20:36:29.657] Done
[2018-11-15 20:36:29.657] Checked set: Focused: 39, Dependents: 0, Dependencies: 25
[2018-11-15 20:36:29.661] sending (23 errors) and (warnings from 46 files) to 1 subscribed clients (of 1 total)
[2018-11-15 20:36:29.661] Status: Error

Seems like there is an error occurring when the LSP attempts to communicate with the flow process.

[bradennapier]

So I was doing a bunch of investigation and logging and things are def pretty weird as there are plenty of places that flow clearly sees the file and even does diagnostics on it... I have a repro setup to show the issue

Repro of Issue

I can swear using flow from cli was still checking the shared directory but now i am realizing even flow is not... on review i've noticed that flow is treating it identical to node_modules

@see:

• https://github.com/facebook/flow/blob/master/src/common/files.ml#L523-L528
• https://github.com/facebook/flow/blob/master/src/common/files.ml#L104-L105
• https://github.com/facebook/flow/blob/master/src/common/files.ml#L179-L180
• https://github.com/facebook/flow/blob/master/src/common/files.ml#L196-L197
• https://github.com/facebook/flow/blob/master/src/common/files.ml#L230-L259
• https://github.com/facebook/flow/blob/master/src/common/files.ml#L292-L293

In this file you will find a few filters for node_modules which always includes the list of all provided. This does make sense logically since they are treating them exactly like node_modules which is what it dictates. However, I can't imagine this being useful for pretty much anything other than matching things like Webpack's resolve.modules (i think thats the property) or Babel's resolve plugin.

I would point out here that the fix I came up with way long ago does still fix the issue but I do believe its due to a bug in their resolution of node_modules files here.

[options]
module.system.node.resolve_dirname=node_modules
module.system.node.resolve_dirname=./src/shared

However, this doesn't provide the fix for how I personally like to setup my libraries (where shared is a folder that is resolved up until a match is found like node_modules so that each respective child folder can have its own set of shared "modules". This has proved to be invaluable in many ways.

Looking at source and trying to learn OCAML a bit along the way to see if I can't determine an easy path to a proper resolution here.

---

It's also worth nothing that importing the file from a watched directory will make it type as needed, although that's not necessarily a solution -- it makes sense as-to why the issue seems to be intermittent. Once the file is actually used by the other parts of the app it will type as expected.

Although when using the base root dir here it definitely is an issue.

---

This behavior seems to have been added as of 0.57.0 which confirms the reasoning for why importing gets them checked.

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

[bradennapier]

@rico345100 not sure if they will merge it but i decided to add a true fix for this issue myself once and for all so I learned me some ocaml!

It's fairly easy to build flow for this if needed.

facebook/flow#7185

This pull request adds a config option that fixes the issue once and for all <3.

If you use OSX I have added the binary to https://github.com/bradennapier/flow-modules-bug-repro/tree/feature/fixed-by-pr-7185 in the bin folder.