Add xo/eslint-adapter and remove xoToEslintConfig

[sindresorhus]

Fixes #875

[fregante]

🙌

[spence-s]

I just wanted to bring this to top level as a comment:

I generally feel this change is a step backwards for xo. It simply makes it more obtuse to get prettier integration and react integration. I think file look ups and internal resolutions is always a brittle design (may work perfectly IDK, but that's besides the point).

Exporting a function was dead simple in comparison and was much more flexible.

The use case is also kind of silly, if you want editor integration with the cli, you should use our editor integrations. They already accomplish the goal of getting your editor to match your cli in a much more graceful way.

---

Pros:

• More clearly separates concerns between the config and the cli (sort of there is still react/prettier/ts integration which are not included in the eslint config, all of which I use)

Cons:

• adds extra internal steps that are non-trivial to look up more files on each run. I think I am wrong about this, unsure, but it probably doesn't affect the xo cli runs?
• Similar to the pro, it still doens't really separate concerns through all the config. I think the xo package jumped in popularity (from about 90k to close to 300k weekly dls shortly after the release of v1) mainly because of xoToEslint and because of the react integration.
• Will force some users (me and my teams) to now have 2 configuration files to maintain instead of 1 to have the same abilities...

Anyway, at best this PR is taking away some flexibility and not giving anything new.

At worst this PR is taking away some flexibility, and not giving anything new.

Why do it?

---

As an alternative that I would fully support: I would propose we leave this adapter out entirely and put the full functionality of xoToEslintConfig into eslint-config-xo.

I think it will take a few more boolean options, and achieve the same flexibility as xoToEslint

xo cli then becomes a very thin wrapper over eslint and eslint-config-xo that provides automatic typescript integration (in the absence of a tsconfig).

Would be simple to provide a migration guide for every use case that way that doesn't feel different to users.

[spence-s]

Another eslint regression that will come from this is that editor integrations watch and detect changes in their config files...

IE eslint editor integration looks for changes in eslint config files and re-lints when changes occur.

It will no longer work like that for users of the adapter, they will need to manually restart eslint in the editor everytime a change is made to the xo config.

xoToEslintConfig supported this naturally, as the config just lived in the eslint.config file. Its just another gotchya to the adapter method.

Not sure if this same thing would affect the eslint cli config caching. Not really sure if that occurs, but if it does somehow, or if they add that in the future, it would have similar issues.

---

I would totally support simple renaming xoToEslintConfig to xo.eslintAdapter() as a function as well :)

[fregante]

xo cli then becomes a very thin wrapper over eslint and eslint-config-xo that provides automatic typescript integration (in the absence of a tsconfig).

Hello! I've been advocating for this for years! 😁

IE eslint editor integration looks for changes in eslint config files and re-lints when changes occur.

It seems we're stuck on the misunderstanding of who this layer is for. Let me try again: if you do not use XO's CLI and IDE integration, you do not need this layer; use eslint-config-xo

Now, if eslint-config-xo doesn't do everything xo can, that's another story. It's what #769 was about.

[spence-s]

Yes - I think its a good point that the function xoToEslintConfig does provide a way for folks to misuse xo cli. Although we clearly state they shouldn't be used together. I haven't given this much thought or seen any issues that this was happening.

Here is my gripe example:

I am using eslint and and eslint editor integration only.

My eslint.config.js is:

import xo from 'xo'

export default xo.xoToEslintConfig([{react: true, prettier: true}, ....otherOverrides ]);

With this change, I now have to add an xo.config.js

export default [{react: true, prettier: true}, ...anyOtherOverrides]

AND I have to keep my eslint.config.js

import config from 'xo/eslint-adapter'

export default config;

---

This is confusing and a step backwards in my opinon.

BUT I would be totally happy if eslint-config-xo supported the react and prettier options, which it does not.

I will be stuck in a weird in between where both my xo editor extension will be activated by the presence of an xo config AND the eslint extension will be activated by the eslint config and in addition, eslint extension will no longer respond to my changes like it normally would as those will now change in the xo config....

We are leaving the react and prettier users (me almost always, and likely a significant portion of other xo users who use xoToEslintConfig and prettier or react integration) in a bad spot with this change I feel.

Its a worst of all world in my opinion.

[fregante]

I would be totally happy if eslint-config-xo supported the react and prettier options

Yes, in my view eslint-config-xo doesn't have any reason to lack configuration/plugins present in the main xo package. If prettier and react are light enough to be part of xo, then they're surely welcome in eslint-config-xo too.

This means more work is needed before xoToEslintConfig is removed.