Support ESLint new config system

[jjangga0214]

Supporting eslint's new config system of eslint.

Note that legacy config system always has require()d plugins and sharable configs, while the system is ESM.

Thus conditional export is great to keep compatibility.

Fixes #1885
Fixes #2220

[jjangga0214]

@sindresorhus

If I try to create a "drop-in" replacement for the old config system, recommended.js would be like this.

import unicorn from '../index.mjs'
import globals from 'globals'

export default {
	languageOptions: {
		globals: {
			...globals.node,
			...globals.es2021
		}
	},
	plugins: {
		unicorn,
	},
	rules: { /* ... */ }
}

However, in the new config system, there is actually no such "root" config.
Everything is kind of overrides, which was implemented comparatively recently on the old config system.
So the main intention of design is chaining.

languageOptions is a root-like options. So I am not sure if it'd be a good convention for a sharable config to provide the default languageOptions in the new config system.

If we include the default languageOptions, then the end-user might feel convenient when they use unicorn as a drop-in config, but otherwise have to manually override languageOptions.

Which one do you prefer?

[jjangga0214]

@sindresorhus And I also want to ask how you think about including files options.

export default {
	files: ['**/*.{js,cjs,mjs,jsx,ts,tsx}'],
	plugins: {
		unicorn,
	},
	rules: { /* ... */ }
}

[sindresorhus]

languageOptions is a root-like options. So I am not sure if it'd be a good convention for a sharable config to provide the default languageOptions in the new config system.

I would prefer to keep including them. We can reevaluate it when the new config system is more mature and has established conventions.

[sindresorhus]

And I also want to ask how you think about including files options.

If that's not the default in the new system, it makes sense to include it here for convenience.

[sindresorhus]

You need to fix the lint issues.

[jjangga0214]

I would prefer to keep including them. We can reevaluate it when the new config system is more mature and has established conventions.

✅ Done.

If that's not the default in the new system, it makes sense to include it here for convenience.

✅ It's not default and I've configured it.

You need to fix the lint issues.

✅ Right. Forgot to do so. Fixed :)

[sindresorhus]

Linting is still failing

[jjangga0214]

@sindresorhus Well.. right, fixed again.

[jjangga0214]

I wrote a guide for the new config system and usage in readme.
Please check it out :)

[sindresorhus]

I think the docs are a bit too verbose. It's not our job to document how the ESLint config system works. We should just show a small example and then link to ESLint docs for more.

[jjangga0214]

It's not our job to document how the ESLint config system works.

Yes, I agree that's 100% right logically.
However, psychologically, a person can feel assured by our a little bit verbose docs.
Eslint's docs only describe how the new system works, not how the specific shareable config(unicorn's) should be configured.
Of course, people can indeed infer how unicorn should be configured after reading eslint's docs, but having assurance is a different matter.
This feeling can trigger people to migrate more confidently, being beneficial at the beginning of the new specification.
So we can make our docs concise later, when people get used to the new config system.

[sindresorhus]

Anything else not addressed?

Just make sure it follows the recommendations in https://eslint.org/docs/latest/extend/plugin-migration-flat-config#backwards-compatibility

[fisker]

just unicorn.configs.recommended.

We can't, we already have unicorn.configs.recommended as legacy config. So unicorn.configs['flat/recommended'] for now?

[sindresorhus]

We can't, we already have unicorn.configs.recommended as legacy config. So unicorn.configs['flat/recommended'] for now?

Yes. Let's do it like that and we can switch it around later on when we fully move to flat config.

[jjangga0214]

This would be better then, IMHO.

import unicorn from 'eslint-plugin-unicorn/flat'

export default [
        unicorn.configs.recommended,
]

[fisker]

This would be better then, IMHO.

import unicorn from 'eslint-plugin-unicorn/flat'

export default [
        unicorn.configs.recommended,
]

We can switch back to unicorn.configs.recommended in the future.

[jjangga0214]

@fisker I know. But I mean /flat entry point until then. I guess maybe you missed reading it?

[fisker]

If we don't add /flat entry, we don't need define exports.

If we add /flat.js file, people need use

import unicorn from 'eslint-plugin-unicorn/flat.js'

and

const unicorn = require('eslint-plugin-unicorn/flat')
// OR
const unicorn = require('eslint-plugin-unicorn/flat.js')

I think unicorn.configs['flat/recommended'] is fine.

[fisker]

I think it's ready for review.