For example
[ignore]
.*/node_modules/.*
[include]
.*/node_modules/@company/.*
[ignore]
.*/node_modules/@company/specific-module/.*
Which would be interpreted as:
node_modules@company, then include itspecific-module from @company, then ignore it.This would provide a lot of flexibility when configuring your flowconfig file since OCaml's regular expression engine doesn't support negative look-aheads and having to enumerate all the possible node_modules I want to ignore except for a specific one is currently a major annoyance.
I ran into this issue too. I have a Lerna repo and use flow-typed install.
index.js.flow it doesn't stub it. But then I ignore *./node_modules/.* so it excludes the ava/index.js.flow[include]
.*/node_modules/ava/.*
From https://flow.org/en/docs/config/ignore/:
Ignores are processed AFTER includes. If you both include and ignore a file it will be ignored.
My workaround is to use flow-typed create-stub ava. I am forced to ignore the types that are there sitting there for me to use. How ridiculous is this!?
@TrySound Could you please comment on this?
I saw you closed a bunch of issues recently saying "just include node_modules".
My node_modules is 467,489 files. This is not feasible.
Don't ignore node modules. They are not checked all anymore. Last versions of flow only looks for direct and transitive dependencies of annotated with flow directive files. First run may take seconds but next should be ok.
Also if you have broken definition in node modules I recommend you to skip it with [untyped] section which treats modules as any.
[untyped]
.*/node_modules/react-native/.*
@TrySound But even with 467,489 files? I use a monorepo, so there are 50+ node_modules dirs. And when they are flattened, this is a lot of files to check.
First run may take seconds
First run never finishes.
There are many people with similar issues. This feature would be an easy fix, but without it there is absolutely no way to use Flow.
Well, flow is fast enough actually. Count of files doesn't matter a lot. The problem I personally met was in flowfixme annotation placed because of laziness. It made flow crazy to never finish. any usually is better fix.
I didn't worked with monorepos, but to be sure check your code for hidden errors.
@TrySound time flow ls > /dev/null takes 45s to run.
$ flow ls > tmp/flow-ls.txt
10.51s user 26.84s system 69% cpu 53.456 total
$ wc -l tmp/flow-ls.txt
480247 tmp/flow-ls.txt
So its watching 480,247 files...when all I really care about is ~500 files.
When I remove the node_modules ignore I got this after 2mins:
time flow check
Worker exited (code: 16)
Worker exited (code: 16)
Worker exited (code: 16)
Worker exited (code: 16)
Worker exited (code: 16)
Worker exited (code: 16)
Subprocess(33823): fail 16Unhandled exception: Worker.Worker_exited_abnormally(16)
Raised at file "map.ml", line 131, characters 10-25
Called from file "hack/utils/collections/myMap.ml", line 15, characters 13-23
Worker exited (code: 16)
Worker exited (code: 16)
flow check 112.86s user 40.39s system 112% cpu 2:16.14 total
It doesn't work - I can't use Flow.
But if this feature were implemented I could use it all day long, which I would love to.
Why are you so adverse to adding this small feature to allow filtering out packages?
@TrySound I think "Allow overriding rules in flowconfig based on order" is too backwards incompatible - however it would be a more complete solution.
What about having an [include_always] option to allow overriding [ignore]. Would be simple to implement, and would allow excluding .*/node_modules/.* except for specified paths.
[ignore]
.*/node_modules/.*
[include_always]
<project_root>/node_modules/ava/.*
The tricky part is how to avoid enumerating every file in a node_modules dir.
Here is a recent commit to add [untyped] config for files that exist but should be untyped. Could be a good starting point to see all the places that need to be updated for adding a new .flowconfig option.
I think "Allow overriding rules in flowconfig based on order" is too backwards incompatible - however it would be a more complete solution.
Is this not what semver is for?
What about having an
[include_always]option to allow overriding[ignore].
That sounds like it would make the "more complete solution" even more difficult to accomplish in the future.
@jcready PR #7317
I'm considering this fixed by https://github.com/facebook/flow/pull/7317 / https://github.com/facebook/flow/commit/6acd727e4493af59d12e79b714de83b023321638
Most helpful comment
@TrySound I think "Allow overriding rules in flowconfig based on order" is too backwards incompatible - however it would be a more complete solution.
What about having an
[include_always]option to allow overriding[ignore]. Would be simple to implement, and would allow excluding.*/node_modules/.*except for specified paths.The tricky part is how to avoid enumerating every file in a
node_modulesdir.Here is a recent commit to add
[untyped]config for files that exist but should be untyped. Could be a good starting point to see all the places that need to be updated for adding a new.flowconfigoption.