question: separating flow-bin initialization from subsequent calls to flow

[nsfmc]

starting the flow server can take a minute or two (depending on the size of the codebase). nuclide and vscode sort of address this by hooking into flow's LSP server to run lint checks, but sublime linter just fires up the process and waits for a response (for however many views could be linted).

is there a way to have sublimelinter spawn the flow process separately from its subsequent calls to lint individual views (i looked at SublimeLinter/SublimeLinter#1250 and it seems like there was movement in this direction, but it seems like it was addressed differently as SublimeLinter/SublimeLinter#1234) I think the latter's approach is pretty sensible, but the initial flow startup time is a fairly deceptive metric.

it could also be that this isn't an issue in practice, that it eventually washes out, but i noticed sublimelinter crashing the plugin host in sublime text with this plugin and suspcted this might be the reason (there is no other logged information which might suggest the problem)

feel free to close, just wanted to ask if maybe there was some infra in place to do this efficiently.

[kaste]

There is always a way. We probably need to run flow start once per flow-bin. However, we never call stop 🤔 ?

[braver]

but sublime linter just fires up the process and waits for a response (for however many views could be linted)

That's what SublimeLinter does. I don't know anything about Flow, but if it uses a language server behind the scenes, you really need a client to interact with it properly and SL isn't that. LSP is what you want here.

However, we never call stop 🤔 ?

Exactly, SL cannot interact with a language server correctly. It's very much out of scope, also because there is already a very nice LSP client in the ST eco-system.

So, I'm going to close, but if I'm not right here, let me know.

[kaste]

Yes you're wrong.

[braver]

Ok ☺️