xojs/xo

Use ESLint-style config options

Opened this issue · 4 comments

j0hnm4r5 commented

Issuehunt badges

Problem

Issue is described here: https://gitter.im/xojs/Lobby?at=5af49381bd10f34a68f18c4d

TLDR; XO's config options are not the same format as ESLint's, leading to increased risk for errors/bugs/confusion, as well as being less powerful (compare XO's "global": [] to ESLint's "global": {}, for example).

Proposal

Use the conventions defined in ESLint's config settings, i.e., objects instead of arrays and uniform naming "env", not "envs".

There is a $60.00 open bounty on this issue. Add more on Issuehunt.

pvdlg commented

The advantage of having global and env options defined as objects is to allow to set some to false. This is useful when extending shareable configuration: if a shareable config you extend define var1 as global and you don't want it, you can disable it in your config by setting it to false.

XO configuration is not extendable. However it allows to extend ESLint shareable config, so there might be cases where one want to disable some global or env values.

On of the challenge is that those 2 options can be set via CLI. That means we would need to use dot notation:

xo --env.foo --env.bar false
// => {env: {foo: true, bar: flase}

We will also have to maintain compatibility with the current array format for backward compatibility and as ESLint supports it as well. So that would require a bit of transformation.

Does that concerns only the env and global options or did you find another one in the same situation?

j0hnm4r5 commented

The only two I was using were env/envs and global, so that's all I can speak for, unfortunately.

The advantage of having global and env options defined as objects is to allow to set some to false.

Just to be clear, the behavior now is essentially that:

"xo" : {
    "globals": [
        "foo"
    ]
}

turns directly into:

"eslintConfig": {
    "globals": {
        "foo": true    
    }
}
sindresorhus commented

As long as the old format with arrays is preserved, I don't mind supporting this. I went with array as I never needed to set the writability of globals.

IssueHuntBot commented

@IssueHunt has funded $60.00 to this issue.