Flow-for-vscode: Changing language to "flow" disables other javascript extensions

[a-s-o]

Hi, I am using vscode-eslint extension which gets disabled with flow-for-vscode changes the language to "flow" for files that have the @flow annotation. Is there a workaround/fix available for such scenarios?

[rpominov]

I have the exactly same problem — also want to use flow and eslint on same files. Is it possible to make this plugin work with "JavaScript" files type?

[nmote]

We ought to be able to do that. That's what we do in Nuclide. I'm not sure if there will be a poor interaction with other JavaScript features in VSCode, though. @bpasero do you have any thoughts?

[bpasero]

I am not sure how well this would work in VS Code. Flow is not valid JavaScript, so we cannot just enable our JavaScript language service and fill in some things on top of it. All the type annotations would be reported as errors and confuse the JavaScript language service.

How does it work in Atom?

[jeffmo]

This is a complete drive-by, but does VS code have a facility to transform code before processing it (similar to what I think Visual Studio did with JSX at some point)?

All of the Flow syntax extensions can be stripped with only local lexical information (there are no type-dependent aspects of the transformation), so it seems feasible that this transformation could run relatively quickly even.

[bpasero]

Currently not.

[nmote]

In Atom it's basically a free-for-all. Out of the box it doesn't do a _ton_ for you, so it's on users to make sure that they don't install conflicting packages. Nuclide's Flow features work fine with Atom's default JavaScript language, but mostly because there aren't really rich features available by default. To my knowledge we haven't had anybody complain that we have enabled Flow for the default JavaScript language.

[bpasero]

Yes that is what I thought. Code tries to have a very powerful support for JS out of the box and I do not see how that would work together with Flow. On the other hand, I like the idea of being able to educate the existing JS language service that there is some syntax on top of it. Very similar to how TS is on top of JS (every JS is valid TS).

[nmote]

Perhaps a good solution would be for the eslint plugin to enable itself for the Flow language?

[RReverser]

You could enable Flow for "JavaScript React" (javascriptreact). That's what other plugins do for code that might support JSX, types and so - and ESLint, code format and some other features works perfectly in that mode. Those that don't support extended syntax, will be still disabled, thus no conflict will happen.

[ericwooley]

sigh, looks like I am still stuck with atom until this is resolved. Thanks for the plugin though, it looks nice!

[fed]

Just in case someone finds this useful... Got eslint to work with flow on vscode by setting "javascript.validate.enable": false on my workspace config as noted on the README. Only extra step i took was to install the flow plugin for eslint and set the parser to babel-eslint on my .eslintrc file. Flow and eslint are now working a charm together :tada:

"parser": "babel-eslint",
"plugins": [
    "react",
    "flowtype"
],
...

[orta]

Yeah, good point, this was resolved - we should close the issue. Thanks @fknussel