Multiple instances of flow server started and not stopped

[peterbe]

trafficstars

Noticed something weird in my Activity Monitor, "flow".

▶ ps ax | grep flow | grep -v grep
52430   ??  Ss     0:44.20 /Users/peterbe/dev/MOZILLA/DELIVERY_DASHBOARD/delivery-dashboard/node_modules/flow-bin/flow-osx-v0.64.0/flow monitor
59390   ??  S      0:21.38 /Users/peterbe/dev/MOZILLA/DELIVERY_DASHBOARD/delivery-dashboard/node_modules/flow-bin/flow-osx-v0.64.0/flow main_1
59393   ??  S      0:00.05 /Users/peterbe/dev/MOZILLA/DELIVERY_DASHBOARD/delivery-dashboard/node_modules/flow-bin/flow-osx-v0.64.0/flow worker process 1/8 for server 59390
59394   ??  S      0:00.05 /Users/peterbe/dev/MOZILLA/DELIVERY_DASHBOARD/delivery-dashboard/node_modules/flow-bin/flow-osx-v0.64.0/flow worker process 2/8 for server 59390
59395   ??  S      0:00.05 /Users/peterbe/dev/MOZILLA/DELIVERY_DASHBOARD/delivery-dashboard/node_modules/flow-bin/flow-osx-v0.64.0/flow worker process 3/8 for server 59390
59396   ??  S      0:00.05 /Users/peterbe/dev/MOZILLA/DELIVERY_DASHBOARD/delivery-dashboard/node_modules/flow-bin/flow-osx-v0.64.0/flow worker process 4/8 for server 59390
59397   ??  S      0:00.05 /Users/peterbe/dev/MOZILLA/DELIVERY_DASHBOARD/delivery-dashboard/node_modules/flow-bin/flow-osx-v0.64.0/flow worker process 5/8 for server 59390
59398   ??  S      0:00.05 /Users/peterbe/dev/MOZILLA/DELIVERY_DASHBOARD/delivery-dashboard/node_modules/flow-bin/flow-osx-v0.64.0/flow worker process 6/8 for server 59390
59399   ??  S      0:00.05 /Users/peterbe/dev/MOZILLA/DELIVERY_DASHBOARD/delivery-dashboard/node_modules/flow-bin/flow-osx-v0.64.0/flow worker process 7/8 for server 59390
59400   ??  S      0:00.05 /Users/peterbe/dev/MOZILLA/DELIVERY_DASHBOARD/delivery-dashboard/node_modules/flow-bin/flow-osx-v0.64.0/flow worker process 8/8 for server 59390
59401   ??  S      0:11.00 /Users/peterbe/dev/MOZILLA/DELIVERY_DASHBOARD/delivery-dashboard/node_modules/flow-bin/flow-osx-v0.64.0/flow file watching process for server 59390

Somewhere in our tooling we're doing it wrong. We're starting it and never stopping it.

[magopian]

I have roughly the same issue on my computer, and I'm not sure it's an issue (it seems to be spawning a bunch of workers, and they wait for file changes to re-check).

Are we sure this is a bug and not a feature?

[peterbe]

Definitely a bug in our tooling. I shouldn't have flow's server still running after i'm done working on DD. At the point of making this screenshot, I had moved away and closed the terminal and editor I had for DD work.

[magopian]

according to https://flow.org/en/docs/cli/ it automatically starts a background server (and you can configure the max number of workers if you want), by design. Are you suggesting we have some kind of workaround that automatically issues a flow stop command?

[peterbe]

Are you suggesting we have some kind of workaround that automatically issues a flow stop command?

Yes. Perhaps we can override yarn start to be yarn start && flow stop. Is that possible? Then you won't have a flow server lingering after you Ctrl-C the dev server.

[magopian]

That's a brilliant idea. Obviously won't work in case you're running something else like yarn run check, but still better than what we have.

If it takes too much time (eg if you restart the server, it kills flow, and then it re-starts it, which takes some time), we'll always be able to revert back to the "standard" behavior.

Good idea @peterbe , I'm +1 on that ;)

[glasserc]

Isn't this the same basic principle as #209? Should we be adding non-standard extensions and behavior in just this one project?

[peterbe]

I have yet to see the light (i.e. the benefit) of flow in a web app so I have to avoid a strong opinion here.

[magopian]

My two cents about the flow benefits: it's just marginally better at helping you spot issues with your types (and helps while refactoring). But it's only useful in places where you don't already have some kind of type system (like proptypes for react components).

If flow was "complete" (eg: didn't need an extra step to check the flow coverage), and had good and helpful error messages, and had a very good type inference, it would definitely make it more valuable.

At the moment, from my limited experience, I'm not sure the ROI is interesting. On the other hand, it might be a good "foundation" to enforce if we want DD to be a "model".

No strong opinions from me here either. I would definitely advocate for using Reason (or even better, Elm) to have a proper type system, if we decide that using a type system is a must have.