Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flow just stops reporting errors #5647

Closed
alexeyraspopov opened this issue Jan 11, 2018 · 14 comments
Closed

Flow just stops reporting errors #5647

alexeyraspopov opened this issue Jan 11, 2018 · 14 comments

Comments

@alexeyraspopov
Copy link

I like using Flow since it provides amazing extension to existent JavaScript code. The type system is efficient, mostly straightforward, and error reports are user-friendly.

I want to thank anyone who's involved in development, it's a great tool.

There is only one thing that bugs be for long time already. You can find it partially reported: #5619, #5586, #5316, #5180, #5495. Sometimes, for some unexpected reasons (mostly after version update), Flow just stops seeing errors (even explicitly made). Me and my colleagues tried tons of ways to work around this: manually killing server instances, looking for temp files that should be cleaned up, etc. Still, Flow can just not report errors.

This is really frustrating since you can't really rely on this tool output. I hope maintainers can prioritize this issue and not just close this ticket as duplication. I'm not familiar with OCaml so there is no even a way to debug this thing locally from my side.

Thank you again for your work and wish we can continue improving Flow.

Alexey

@apsavin
Copy link
Contributor

apsavin commented Jan 12, 2018

#5586 is closed, #5316 is obvious duplicate of #5180 - but #5180 has a solution and can be closed too. #5495 does not provide enough info.

Can you show your .flowconfig?

@alexeyraspopov
Copy link
Author

My .flowconfig is:

[libs]
typings/

[options]
module.system.node.resolve_dirname=node_modules
module.system.node.resolve_dirname=src
esproposal.class_instance_fields=enable
esproposal.class_static_fields=enable

I use Node 8.6, macOS Sierra, Flow 0.63.1

@apsavin
Copy link
Contributor

apsavin commented Jan 14, 2018

You need to remove this part from your config:

[options]
module.system.node.resolve_dirname=node_modules
module.system.node.resolve_dirname=src
esproposal.class_instance_fields=enable
esproposal.class_static_fields=enable

@apsavin
Copy link
Contributor

apsavin commented Jan 14, 2018

And instead of module.system.node.resolve_dirname=src use something like

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

for each directory in src

@alexeyraspopov
Copy link
Author

Could you please explain why do I need to remove that part of my config? It is what I found in Flow docs and used based on what I’m able to do in JS with CRA setup.

@apsavin
Copy link
Contributor

apsavin commented Jan 14, 2018

You don't have to declare stuff like these because it works by default:

module.system.node.resolve_dirname=node_modules
esproposal.class_instance_fields=enable
esproposal.class_static_fields=enable

You must not use

module.system.node.resolve_dirname=src

because it works not as you think it works. It marks src as node_modules-like folder. Files in node_modules flow treats in a special way so it causes problems. Use module.name_mapper instead.

@jpolo
Copy link

jpolo commented Jan 14, 2018

@alexeyraspopov We have same kind of problem in my team too... It started to behave like that around 0.57.0-0.58.0 .
After saving some files, it seems to "unlock" a partial stack of error. So while coding, flow seems to work in an indeterminate manner which is very frustrating.

@apsavin
Copy link
Contributor

apsavin commented Jan 14, 2018

@jpolo It was introduced here #869 (comment)

@cprodescu
Copy link

@apsavin Excellent catch!

@cprodescu
Copy link

If getting rid of resolve_dirs requires non-trivial amount of work, a temporary workaround is to add an entry point from outside src/ to the entry point of your app.

In the example bellow <PROJECT_ROOT>/src/index.js is the entry point of the app and we add a file <PROJECT_ROOT>/__flow-tests__/flow-index.js which references it:

/* @flow */
/* This is necessary to mitigate https://github.com/facebook/flow/issues/5647 */

import '../src';

@alexeyraspopov
Copy link
Author

alexeyraspopov commented Jan 14, 2018

It marks src as node_modules-like folder. Files in node_modules flow treats in a special way so it causes problems. Use module.name_mapper instead.

@apsavin, is there any explanation in docs regarding this behavior?

@apsavin
Copy link
Contributor

apsavin commented Jan 15, 2018

@alexeyraspopov I'm not sure there is.

@alexeyraspopov
Copy link
Author

I guess I saw some explanation of "lazy" mode when it comes to reading node_modules folder. I though, maybe it would be better to link this explanation to config page, so users like me won't use that options for things it wasn't created for.

@mnn
Copy link

mnn commented Jul 23, 2018

And instead of module.system.node.resolve_dirname=src use something like

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

for each directory in src

This is seriously the right "solution"? Instead of 1 option for every module resolve root configured once only at starting a project, now it requires us to manually write all modules for all resolve module roots? So whenever I'll add a component (which is inside its own module), I must also manually add a line to flowconfig? This is very cumbersome and actually might be a reason to not use Flow...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants