Does not work if project root is not the flow project root

[lloiser]

Given a project folder where the .flowconfig is not located in the root folder but somewhere in a nested folder (e.g. because only a part of the entire project uses flow atm). Then the flowtype language server is not able to determine the version that is required.

[2017-08-24 15:18:14.682] [INFO] flow-versions - Determining the version of flow for your project...
[2017-08-24 15:18:14.689] [ERROR] flow-versions - There was a problem obtaining the appropriate version of flow for your project. Please check the extension logs.
[2017-08-24 15:18:14.745] [ERROR] flow-language-server - unhandledRejection { Error: Unhandled method window/showMessageRequest
    at new ResponseError (/Users/lloiser/.atom/packages/ide-flowtype/node_modules/vscode-jsonrpc/lib/messages.js:46:28)
    at handleResponse (/Users/lloiser/.atom/packages/ide-flowtype/node_modules/vscode-jsonrpc/lib/main.js:421:48)
    at processMessageQueue (/Users/lloiser/.atom/packages/ide-flowtype/node_modules/vscode-jsonrpc/lib/main.js:249:17)
    at Immediate.<anonymous> (/Users/lloiser/.atom/packages/ide-flowtype/node_modules/vscode-jsonrpc/lib/main.js:233:13)
    at runCallback (timers.js:651:20)
    at tryOnImmediate (timers.js:624:5)
    at processImmediate [as _immediateCallback] (timers.js:596:5) code: -32601 }

Setting the flow bin (from node_modules/.bin/flow) manually in the settings (Path to Flow executable) works. The problem is that it will only work for exactly this project, once I switch to another project it uses the wrong flow bin...

Any ideas how this could work?

[wbinnssmith]

Yeah this is an excellent point, and I imagine is probably a common usecase.

We can probably start looking upward for a flowconfig on every opened file and spawn a new flow for each unique flowconfig we encounter. Though I'm not sure if this is best implemented in the server itself or in the editor integration.

@damieng, if we implement this in the client, can atom-languageclient handle multiple servers of the same type in a given root? The API for AutoLanguageClient seems to imply that there should only be one.

[damieng]

There is definitely the assumption of a 1-to-1 mapping between roots and language servers right now. I'm not averse to changing things as long as the primary current use case does not become more complex.

[saadq]

Hey all,

If the package only looks upward for a .flowconfig, is there any way for it to work for a situation like this:

Let's say you have a folder structure like so:

.
├── client
│   ├── src
│   └── .flowconfig
├── server
│   └── src

Because the .flowconfig is in root/client instead of the root, the package doesn't seem to find it, so flow doesn't seem to work in this case. Is there any workaround to this or is it necessary to open only the client package as the root project folder in Atom?

[aray12]

Hey are there any update on this?

[gausie]

I have a monorepo that is suffering from this issue (which is weird coming from Facebook who make extensive use of them!)

I moved my flowconfig up to the top level, but of course get the issue that imported modules do not correctly resolve (because they are installed in a package.json lower down in the project heirarchy.

Mostly an FYI for people thinking that that would be an acceptable workaround.

[pascalduez]

Mono-repos are a good use-case for this, for instance multiple packages per project that possibly use different Flow versions or config.

That's something the flow-ide plugin support out of the box.

[alex35mil]

+1 monorepos user here. I don't have multiple flow versions per project, but in few of my projects flow's root is not the root of the opened project [details].