fisker Cheung

After learning the new config system. I don't think adding those exports is the right thing. My recommend config example: ### Preset ```js import eslintPluginUnicorn from 'eslint-plugin-unicorn'; export default [...

So, I think we only need update `configs/recommended.js` to remove `env`, `parserOptions`, and `plugins`, add `languageOptions`. The `index.js` file should like this: ```js const eslintPluginUnicorn = { rules: { ...loadRules(),...

If breaking the legacy config is your concern, adding new entry is better. Anyway, we should not enforce people to use `import` to import the new entry `eslint-plugin-unicorn/recommended`. It should...

> there's no `.configs` property I don't think so. `plugin.configs` will be kept for a long time. Using `plugin.configs` will make manual config easier, they don't need import two entries.

Turns out it's recommended to use `plugins.configs` in the RFC https://github.com/eslint/rfcs/tree/main/designs/2019-config-simplification#plugins-specifying-their-own-namespaces

> "there's no .configs property in the spec of the new config system" I mean we'll keep `.configs` for a long time, since the old config/plugin system still functional.

In that case, do you think this should be fixed? > I'm using `"raw"` because the default `"html"` format cause `\n` added between `` which is also a bug

Thanks anyway.

How about `consistent-undefined-check`, allow one of these two? Personally I always use `typeof`.

When it's undefined variable, `foo === undefiend` will throw ```text foo === undefined VM227:1 Uncaught ReferenceError: foo is not defined at :1:1 ```