Can't run flow in cmd when VS Code is open in Windows

[edele]

The only difference is C and c drive letters:

flow is running on a different directory.
server_root: c:\Users\edele\flowtest, client_root: C:\Users\edele\flowtest

But I think paths are the same because Windows paths are case-insensitive.

server_root was created by Flow Language Support for VS Code. And the error is thrown whenever I run yarn run flow in cmd.exe to see full list of errors in a project.

Looks like the issue originates in vscode.TextDocument.uri.fsPath which "normalizes" drive letter to lowercase according to documentation: https://code.visualstudio.com/docs/extensionAPI/vscode-api#Uri

Still thinking on a possible solution.

1. Should drive letter be forced to uppercase in Flow Language Support plugin because flow-bin uses uppercase?
2. Should flow-bin change the way it decides if server_root and client_root are the same just for Windows?
3. Am I missing something?

BTW. Just look at Microsoft nowadays. It's modern vibe feels so good. We have to consider Windows as a viable platform now.

[mrkev]

After some quick skimming I didn't find where the uppercase C:\ comes from, but I found where the comparison is done:

flow/src/server/commandHandler.ml

Line 29 in 347281f

if server_root <> client_root then begin

I guess the paths could be normalized to lowercase before comparing on windows? Not 100% sure it wouldn't have negative effects, but feel free to PR and ping me. For reference this PR does a check to discern platform: #6573

[codespitzer]

Has a solution/workaround been discovered for this issue?

[SergioMorchon]

Any news on this?

[ArmorDarks]

I guess the paths could be normalized to lowercase before comparing on windows? Not 100% sure it wouldn't have negative effects

that should be fine since on Windows paths aren't case sensitive, as it happens to be on Linux.

[edele]

You can also run flow check instead as a workaround.

[Diggsey]

Same issue here - windows 10.

[ArmorDarks]

Any chances to give that issue priority? That would so much improve dev experience on Windows.

The fix should be quite straightforward, as Windows paths are case insensitive, which means that on win platform all paths can be simply lowercased before comparison.

It's just the OCaml thing that stops from making a PR... Too stupid, sorry 😥

[edele]

@ArmorDarks did you try running flow check instead of just flow?
It worked for me. If it wouldn't do it for you then could you tell me about your use case?

[ArmorDarks]

@edele Yeap, flow check works, thanks. But the issue with flow and flow status is still there.

[edele]

@ArmorDarks which issue?

IIRC, the issue with running flow on win32 is that it tries to reuse existing flow server and it fails on path mismatch which is because of missing if (win32) {pathToMatch = pathToMatch.toLowerCase()}. But flow status will not try to reuse existing server.

So which issue are you talking about? 🙂

[ArmorDarks]

@edele you really force me to link you to your own comment, which exactly describes the issue #6592 (comment)

[edele]

Some may find this helpful https://gist.github.com/edele/540b2ccb2e773e18e19a3e489336126b

You close VS Code, run kill-flow.bat and start anew with a fresh working state

[jeffvandyke]

Same issue at our place too, and using either https://github.com/jstwister/vscode-flow-ide or https://github.com/flowtype/flow-for-vscode both have this issue. It's highly annoying for wanting to run flow from any command line as an npm test command, and we can't be restarting VS Code whenever we want to run an npm script that involves flow. flow check takes 2 minutes to run on Windows thanks to small files, so we really need the regular flow to connect to the server.

Literally the only difference between server_root and client_root is the casing of d:\Repos vs D:\Repos Even the rest of the path preserves case.

[amankkg]

As a workaround, one could just pass PROJECT_ROOT manually, e.g. npx flow c:\some\path