Allow importing a config from package.json

[sholladay]

Could we add xo.extend functionality back to the CLI, specifically for package.json (not config files)?

package.json:

{
    "xo": {
        "extend": "my-custom-config"
    }
}

I am in the process of updating my linting setup from XO 0.x to 1.x and using flat config in my shareable Tidy config, which just contains some rule overrides where I disagree with XO's choices.

I see the benefits of the flat config, including removing the extends property from the config files in favor of imports and spread operators. It is great. However, the update also removed the ability to extend XO from package.json and that's a problem because, unlike config files, package.json doesn't have the ability to import anything.

The only way I've found to deal with this is to make a nearly empty xo.config.js file:

export { default } from 'my-custom-config';

I would prefer to avoid the clutter by keeping this in package.json, as before, and not have xo.config.js files everywhere for such a simple use case. All I want to do is override a handful of rules in every project without making a mess.

[spence-s]

We support what eslint supports. They support extends as a string, although I don't think they support your use case.

If we were to write our own extends logic, we'd open a huge can of worms and very likely make popular configs and plugins incompatible with xo.

We also don't treat package.json special. Its just a limited form of serializable parts of the config file. Useful for turning off rules which is one of the main usecases of a config in package.json.

[sholladay]

Ah, I wasn't aware that ESLint had added their own extends option. And it behaves differently. So, if I understand correctly, XO had no choice but to remove its own handling of extends when it updated to ESLint v9, because otherwise it would accidentally block using this new ESLint feature.

I see two possible solutions:

1. XO tries to import() the extends value first and falls back to passing it to ESLint. Maybe a little too ambiguous, but it avoids needing to change any types and just adds to what extends can already do via ESLint.
2. Bring the option back under a new name. I would propose xo.use.

package.json:

{
    "xo": {
        "use": "my-custom-config"
    }
}