The issue has been closed
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".
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?
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
}
}
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.
@issuehunt has funded $60.00 to this issue.
IssueHunt