Xo: Add support for Flow

[ghost]

It seems that XO does not support Flow.

babel-eslint could be used as the default parser and an optional option flow could be added for configuration.

eslint-plugin-flowtype could be used

[ghost]

Would love to see

{
    "flow": true
}

[sindresorhus]

babel-eslint is intentionally not the default parsers. It used to be, but I removed it as it was super buggy and caused lots of problems. You can easily set it as the parser yourself. I don't want an option for everything. If I add a flow option, people will want a typescript option, and then the floodgates are open.

https://github.com/sindresorhus/xo#parser

[sindresorhus]

I can keep this open so I remember to add a tip about it to the readme: https://github.com/sindresorhus/xo#tips

[ghost]

@sindresorhus, since you don't want to support Typescript, it would be a good idea to support flow for
static-type checking

[pvdlg]

That would be a good idea to add eslint-plugin-flowtype rules.

I would propose to:

• Create a new eslint-config-xo-flow shareable config with the eslint-plugin-flowtype plugins, some rules and the parser set to babel-eslint
• Update the XO documentation to indicate that using flow require to add eslint-config-xo-flow to the extends option

What do you think @sindresorhus ?

[jorgegonzalez]

Why not add a "flow": true option to #326 and just have all of this working out of the box?

My favorite thing about XO is that I can npm install --save-dev xo and everything just works. Having to deal with installing another config and another plugin and another parser is not very friendly when it can all be bundled as a config option.

[sindresorhus]

Create a new eslint-config-xo-flow shareable config with the eslint-plugin-flowtype plugins, some rules and the parser set to babel-eslint

Sure, I can do that.

[sindresorhus]

I wish we could make it just work, like @jorgegonzalez said. The problem is that I don't really want to depend on babel-eslint as it depends on babel which is a very heavy dependency...

I wonder if we could make a package like xo-flow, which would come with eslint-plugin-flowtype, eslint-babel, and when installed it tells XO to use Flow-mode.

[jorgegonzalez]

@sindresorhus @pvdlg Can I start work on an eslint-config-xo-flow or an xo-flow?

[jorgegonzalez]

We could also add an xo --init=flow option, which triggers an install of an eslint-config-xo-flow, so that way it's not a direct dependency of XO. Similarly for TypeScript.

[sindresorhus]

Can I start work on an eslint-config-xo-flow

I made https://github.com/xojs/eslint-config-xo-flow. Was easier for me to make the initial version, as I'm very opinionated the rules, than to comment on everything afterward. I'm happy to consider changes to it though.

[sindresorhus]

We could also add an xo --init=flow option, which triggers an install of an eslint-config-xo-flow, so that way it's not a direct dependency of XO. Similarly for TypeScript.

Yup, that's a good idea. I plan to remove --init from XO itself and make it a standalone CLI. It's already a standalone module. Same changes as done here: https://github.com/avajs/create-ava/commit/f833b27fb8cc0ae5d9a318e0490e16bb6e51b850 Help welcome for that. Then it would be: npm init ava --flow. See: https://github.com/xojs/xo-init/issues/16

[sindresorhus]

I wonder if we could make a package like xo-flow, which would come with eslint-plugin-flowtype, eslint-babel, and when installed it tells XO to use Flow-mode.

@pvdlg What do you think of this idea? That would reduce the step of adding TS/Flow to only one command: npm i xo-typescript or npm i xo-flow.

[pvdlg]

I don't think it's great idea to have multiple packages. That would basically replace an option by different package. And that create more maintenance work.

We should handle Flow and Typescript the same way we handle React, by creating a shareable config: https://github.com/xojs/eslint-config-xo-react#use-with-xo. We can make it more explicit in the README that in order to use React. Flow or Typescript you need to add the proper extend.

React is far more popular than Flow or Typescript so I'm sure there is a lot of folks using XO to lint React apps and so far having to add "extends": "xo-react" in the XO config doesn't seems to be in issue.

[sindresorhus]

@pvdlg The problem is that it's not just about adding "extends": "xo-typescript". They also need to install: eslint-config-xo-typescript typescript-eslint-parser eslint-plugin-typescript Shareable configs cannot have dependencies (https://github.com/eslint/eslint/issues/3458)...

[pvdlg]

That's exactly the same situation for React, per the eslint-config-xo-react doc:

$ npm install --save-dev eslint-config-xo-react eslint-plugin-react

[jorgegonzalez]

You could change the listed peer dependencies in eslint-config-xo-flow/typescript to dependencies. Then add the options xo init flow and xo init typescript which will trigger the following:

execa('npm', ['install', '--save-dev', 'eslint-config-xo-typescript']);

• This prevents the configs and their large dependencies from being direct dependencies of XO
• The user won't need to install anything other than XO
• You won't have to worry about separate xo-flow and xo-typescript packages
• The "extends": "xo-typescript" and "extends": "xo-flow" could also be added to package.json programmatically
• Same thing could be done for React

[jorgegonzalez]

Oh shareable configs can't have dependencies ...

The packages can all still be installed programmatically.

[pvdlg]

Yes adding an option to the xo-init command seems to be the best choice.
That would be great to add one for React as well.

In the main XO code the only we would have to do is add .ts and .tsx to default extensions.

[sindresorhus]

The packages can all still be installed programmatically.

I don't think that's a good idea. Too surprising.

[pvdlg]

Now that we have https://github.com/xojs/eslint-config-xo-flow can this issue be closed?