Migrate to flat config

[fisker]

No description provided.

[fisker]

eslint-config-xo-typescript may need expose an array instead of an object https://github.com/xojs/eslint-config-xo-typescript/blob/3271346cfa8cdc2d44bee64718399eea9f603ea3/index.js#L737

Should we expose an array here too?

So user can

export {default} from 'eslint-config-xo';

and

import eslintConfigXo from 'eslint-config-xo';

export default [
-	eslintConfigXo,
+	...eslintConfigXo,
];

[fregante]

eslint-config-xo-typescript

Do you need separate packages anymore? My understanding is that configurations are now configurable, so you can just expose a function and pass typescript:true, spaces:4, etc if needed. See https://github.com/antfu/eslint-config?tab=readme-ov-file#customization

Perhaps you can work on a baseline eslint-config-xo first and the progressively integrate the rest after a successful launch.

[fisker]

But eslint-config-xo-typescript need extra packages installed/imported, it's not good if user only uses js syntax.

[fisker]

Should we expose an array here too?

Looks like shared config can be an object, maybe arrays will be flattened too, if it's true, we don't need care, I'll test.

[fregante]

But eslint-config-xo-typescript need extra packages installed/imported, it's not good if user only uses js syntax.

That hasn't been a limiting factor for XO itself, which includes TypeScript and Prettier whether you use them or not.

In an ideal world, eslint-config-xo contains all the logic XO needs, and XO becomes a wrapper around eslint and eslint-config-xo without a lot of glue. This way users can choose xo-cli or eslint + eslint-config-xo without losing much.

[fisker]

Waiting for answers eslint/eslint#18563

[sindresorhus]

I don't want to merge the TS one into this one yet.

The "space" config should be merged into this one though. It was only a separate package because of ESLint limitations.

[fisker]

Let's export an array? Check discussion in eslint/eslint#18563

[sindresorhus]

👍

[voxpelli]

I would go with generating the config through a function instead of through static objects (see review comment) as one can now be sure that the config will be used from a javascript file and hence it can be better to expose a typed factory function rather than relying on setting up files for all the possible combinations of options.

I would also consider eventually upstreaming eslint-config-xo into xo and let it be run through either xo or be extended and run through eslint.

The eslint-config- prefix is no longer needed to signify that an ESLint config can be returned.

[voxpelli]

I opted for a neostandard({ semi: true }) style to construct the config in neostandard. Have you considered doing that instead of /browser? Having something like export default xo({ browser: true })?

That way you can have space, browser etc exposed without having to have files for the combinations as well, like space/browser

[voxpelli]

What's the benefit of this over having the space config be its own config? The latter is what I opted for in neostandard

Suggested change

	export default [
	{
	...config,
	rules: {
	...config.rules,
	indent: [
	export default [
	config,
	{
	rules: {
	indent: [

I would do something like:

import base from './configs/base.js';
import browser from './configs/browser.js';
import space from './configs/space.js';

export default [
  base,
  browser,
  space,
];

[voxpelli]

A benefit of having them as separate (+ including names for each one of them) is that its very clear which config that leads to which config. See example here from the config inspector generated for neostandard: https://neostandard.github.io/neostandard/configs

[fregante]

I would also consider eventually upstreaming eslint-config-xo into xo and let it be run through either xo or be extended and run through eslint.

xo includes cli modules (as well as the whole of Prettier), which eslint wouldn't use. Since there won't be a xo-cli package I think it can stay as eslint-config-xo

[fisker]

Sorry that I didn't get time to check feedbacks.

[Primajin]

Hey, do you think it makes sense to add a legacy support like they did over here in vitest: https://github.com/vitest-dev/eslint-plugin-vitest/pull/434/files

[voxpelli]

@Primajin Open a new issue for that discussion. Personally I would say: No, it does not make sense :)