Issues which block usage of the tool

[vjpr]

I want to collect a list of issues that prevent Flow being able to be actually used for a code base.

This is mainly missing config options, or performance issues related to missing config options. This list is just for basic stuff. Other issues like community, tooling, etc. are things that can improve over time, but if Flow cannot be run on your codebase, then there is not choice but to move to TypeScript.

• doesn't support module aliases (there is a PR to fix) - [FEATURE] Add module_alias resolution capabilities #7185
• not able to ignore all node_modules without getting "cannot find module" errors, and being able to include node_modules packages that do have typings (ignore config precedence) - Prevent reading all node_modules when using [untyped] #7431 Don't typecheck or load files under node_modules/ unless they're imported by flow-typed files #869
• adding node_modules to [untyped] still makes the server look for them on startup which makes server start needlessly slow (which you have to deal with on every config change). I want to ignore all node_modules, but have import 'foo/bar' work. This is not possible.
• search upwards for flow-typed dirs - Support flow-typed directories in yarn workspaces #5183
• errors in libs in flow-typed dir cannot be ignored by any config option - How to ignore a specific lib? #6256

Comment and I can update the list so we have a prioritized list of community issues that are preventing usage of the tool. As long as we can use it on our code bases in the first place, then we would be happy to wait for other issues to be fixed.

Maybe having a tag called "blocks community usage" would be good to label issues that fit this description.

[nmote]

I appreciate the feedback, and I think this is a good list of high priority work for the community. I spent some time today looking into #7185, and I just left a comment there. I also left a clarifying question on #5183. I'll spend some more time looking into the problems mentioned here on Monday.

I have one question associated with your bullet point that's not associated with an issue.

adding node_modules to [untyped] still makes the server look for them on startup which makes server start needlessly slow (which you have to deal with on every config change). I want to ignore all node_modules, but have import 'foo/bar' work. This is not possible.

I'm not intimately familiar with this code, but the untyped docs claim that modules listed under that heading aren't even parsed. Is that incorrect?

[vjpr]

@nmote There is full detail here: #7431

This is odd because when I do the following:

[untyped]
.*/node_modules/.*

I see this message slowly counting up to 200K files.

Please wait. Server is initializing (👻  parsed files 88000): /

The server takes longer to start. So either untyped is broken, or the parsed files message is broken.

If the parsed files message is broken, then the slow down must come from reading 200K files instead of 3000. This is assuming that when I ignore .*/node_modules/.*, it will not search inside of any node_modules dir...which I'm not sure is the case.

---

flow ls --explain shows ImplicitlyIncluded for every node_module file.

ImplicitlyIncluded    /xxx/node_modules/.registry.npmjs.org/rebass/2.3.4/node_modules/rebass/dist/Text.js

[vjpr]

So it seems that it is always scanning all files, even in node_modules. This is another huge startup performance issue. Seems like there is no way to not touch node_modules. In node, require('glob', {ignore: '**/node_modules/**'}) easily does this...

# untyped node_modules
./node_modules/.bin/flow ls --all > /dev/null  2.59s user 18.63s system 55% cpu 38.585 total
./node_modules/.bin/flow ls > /dev/null  8.32s user 15.99s system 58% cpu 41.849 total

# ignore node_modules
./node_modules/.bin/flow  0.21s user 0.11s system 1% cpu 32.303 total
./node_modules/.bin/flow ls > /dev/null  8.52s user 15.35s system 55% cpu 42.959 total

[bradennapier]

I personally think you may be holding onto issues long solved since around 0.6x.

1. Adding node modules to ignore is a terrible idea. It breaks any modules that export .flow.js files side by side (like all my libs) and breaks the context flow can generate when you have full flow typing.

2. Using “flow-typed” will stub all remaining modules so they provide your needs

—-

I have not run into noticeable peformance issues with this method since the node module resolution was greatly improved.

I believe they used to parse ALL files in node modules whereas now they build their own dependency tree and traverse that, relying on flow-typed if no .flow.js option exists.

For me untyped would be to have flow “ignore” some internal part of a repo which is problematic when trying to build a flow project, likely exclusively for projects in process of migration to Flow.

Of course I’ve never used the feature so I may be wrong in my understanding.

[bradennapier]

I’d also take this time to also mention that type script is similar. It will always say cannot find module unless you install the required types stub, granted they have a massive library. Flow typed is pretty solid and it’s honestly very easy to convert (some tools to do it automatically do exist).

I’d recommend you install and stub out your modules using the flow typed package which will fix your issues by default.

—-

My company is toying with type script and while I have enjoyed it a bit, one thing I’d mention immediately as the difference is that type scripts method of type safety is far more “surface level”.

It doesn’t feel like it gets to the logical errors in how you’re doing things on a deep level like flow does. Flow feels like it’s actually trying to understand “why” you’re doing something vs typescript just kind of being a one level “yeah this checks out” thing.

With flow I wrote a pretty large scale application with 100% coverage and it worked the first time. I had almost zero errors to fix. TS ... well ... not the case. You just can’t make it strict enough.

• Flow feels almost as if it were actually running my app and acts like an interpreter whereas TS is just checking that you meet basic needs for each function
  • Type script hasn’t caught a single logical error but has ensured basic type safety.
  • It does make flow harder to do properly for sure though.
• There’s a TON to be said for the fact flow is just JavaScript and lives with standard tooling.
• While TS is fixing it and ditching tslint, the loss of eslint and Babel alone without big trade offs makes me cry at night
• Flows strict object types are a big enough deal to remain with flow.
• Flow has 100x more potential with the right roadmap.
  • in combination with things like prepack believe it can change the entire js ecosystem in a major way and save us from ourselves.
  • it has a long way to go. TS is a stable and mature project while flow is still in infancy. It can’t be relied upon the same as TS for now.

I will say Typescripts developer experience trumps flows 100 times over though. It’s rock solid...

Ok rant over - my bad :) tangents are my specialty

[vjpr]

1. Adding node modules to ignore is a terrible idea. It breaks any modules that export .flow.js files side by side (like all my libs) and breaks the context flow can generate when you have full flow typing.

I have 200K total files in a monorepo.

With Flow, the server takes >1min to start. The server needs to be restarted after every code config change.

With TS, I simply add a tsconfig.json file, change file extension to .ts, and it typechecks almost instantly.

2. Using “flow-typed” will stub all remaining modules so they provide your needs

In a monorepo this is painful. Each package can require its own version of a dependency. If I have 1000s of dependencies, flow-typed will be very slow.

The advantage of Flow is that you can just add a comment to top of file and start adding types. But it is just so much slower than TS.

I’d also take this time to also mention that type script is similar. It will always say cannot find module unless you install the required types stub

Nope. Just tried it. It reports if the package is missing, but does not complain about missing types.

I’d recommend you install and stub out your modules using the flow typed package which will fix your issues by default.

I used to do this. It took heaps of time, and to get it to work with a monorepo was tedious. And still, without support for using a flow-typed directory per package, it will never work properly.

TS setup was extremely easy, its orders of magnitude faster, and supports config files per package, module aliasing, and monorepos with their project references feature.

one thing I’d mention immediately as the difference is that type scripts method of type safety is far more “surface level”.

For me, I simply cannot get it to run on my codebase, hence the issue.

---

• Flow feels almost as if it were actually running my app and acts like an interpreter

You should try flow-runtime. Compile-time and runtime type checking is really great.

• There’s a TON to be said for the fact flow is just JavaScript and lives with standard tooling.

Yep, why I chose it in the first place.

• the loss of eslint and Babel

You can use Babel with TS. Flow is better at supporting new lang features though if that's what you meant.

• Flow has 100x more potential with the right roadmap.

I always preferred Flow, but the DX is terrible and I could never get it to work on my monorepos. When I read through the Typescript docs, it just seems so much more flexible in terms of configuration, to support modern JS - like config's per package, project references for monorepos, and module alias support. A ton of time has gone into the DX work, whereas Flow has ignored this.

[techieshark]

IMHO a huge issue which may motivate migration to TS for users is the fact that it's easier to work with library definitions (e.g. more 3rd party libs have definitions, and DefinitelyTyped ecosystem/website seem more user-friendly).

Apologies if that's off topic for this issue on Flow's repo, but additional support on these two repos/projects could be helpful (IMHO):

• https://github.com/joarwilk/flowgen
• https://github.com/flow-typed/flow-typed