Use ESLint directly instead of xo

[JounQin]

It works differently with ESLint.

xojs/xo#671

It is slow

xojs/xo#515
xojs/xo#558

And no way to debug

xojs/xo#188

No root option, so global ESLint config like ~/.eslintrc will be used unexpectedly.

And all its functionality can be replaced by ESLint directly.

@wooorm

[wooorm]

I don’t quite understand.

• Different: It being different, namely that it has useful features, is why I use xo. It looks like in 671, there are rules that xo turns on, which ESLint doesn’t default to, which don’t work with eslint-mdx?
• Slow: It can be slow, but that’s because it includes a lot of useful rules
• Debugging: My guess is that it has the same debugging as ESLint: DEBUG="*" xo...
• Root: The root option you mention seems to be a problem with VS Code? If possible, I recommend not using a global ~/.eslintrc. Otherwise, you can typically tell VS Code plugins that they need to be configured in a project. I believe xo has such an option

And all its functionality can be replaced by ESLint directly.

I find the functionality that xo provides useful and I don’t want to manually handle ESLint

[JounQin]

1. no-unused-expressions is enabled in .eslintrc of Works differently with ESLint? xojs/xo#671, but it results different

[JounQin]

npx xo --print-config test.mdx > .eslintrc.json

Seems the difference is

{
  "no-unused-expressions": [
  2,
  {
    "enforceForJSX": true,
    "allowShortCircuit": false,
    "allowTernary": false,
    "allowTaggedTemplates": false
    }
  ]
}

[wooorm]

Perhaps eslint-mdx can be made to work with that ESLint configuration?

[JounQin]

Maybe, I need to read no-unused-expressions source code tomorrow.

Going to sleep now, seems I'm not very sober at this moment.

[wooorm]

good night! ;)