eslint-plugin-regexp
eslint-plugin-regexp copied to clipboard
Support flat config (eslint.config.js)
See https://eslint.org/docs/latest/use/configure/configuration-files-new
I'm still wondering how best practice is to export a new shareable configuration 🤔 I would like to export using the same method as the popular eslint-plugin, but I don't know what it is yet.
Otherwise, I can think of the following method:
- Use
configs.recommended
namespace.plugin.configs.recommended
is reserved for legacy configurations. I don't want to change it for backwards compatibility. - Use a new namespace.
I don't want to use names like
plugin.flatConfigs.recommended
, andplugin.configs.flatRecommended
. "Flat" quickly becomes meaningless. Also, I think it is difficult to understand the difference betweenconfig
andconfigs
. I'm not sure what namespace to use instead that would be easier for people to use. - Use new
*.js
file. e.g.import { recommended } from 'eslint-plugin-regexp/configs'
. - Make
plugin.configs
an object-like function with properties. e.g.plugin.configs('recommended')
.
eslint-plugin-unicorn
decide to use plugin.configs['flat/recommended']
, its used in ESLint blog post, see also discussion.
Thank you for sharing the discussion! I will check it.
This is just a note of my research. I looked into how each plugin supported flat configurations. By the way, none of the plugins I maintain support flat configurations yet.
plugin.configs['flat/recommended']
- eslint-plugin-unicorn https://github.com/sindresorhus/eslint-plugin-unicorn/blob/eb5af8bbd95f6bce3ad550c767bb63cec835719e/readme.md#preset-configs-eslintconfigjs
- eslint-plugin-jsdoc https://github.com/gajus/eslint-plugin-jsdoc/blob/7461e0182827af0c6355dfeec50315953c6fb3de/README.md#user-content-eslint-plugin-jsdoc-configuration-flat-config
- eslint-stylistic https://github.com/eslint-stylistic/eslint-stylistic/blob/5d2c1d7dfb366fcc4186b68187709657d2dc702c/docs/guide/config-presets.md#static-configurations
plugin.configs['recommended-flat']
- eslint-plugin-n https://github.com/eslint-community/eslint-plugin-n/blob/4265094e1235dbd741f13ac6c70dd6b2f848452d/README.md#eslintconfigjs-requires-eslintv8230
import recommended from 'eslint-plugin-x/configs/recommended'
- eslint-plugin-eslint-plugin https://github.com/eslint-community/eslint-plugin-eslint-plugin/blob/6b53c5b7b8bc9e19dcb86796ab29019f89c449fc/README.md#eslintconfigjs-requires-eslintv8230
- eslint-plugin-react https://github.com/jsx-eslint/eslint-plugin-react/blob/9f4b2b96d92bf61ae61e8fc88c413331efe6f0da/README.md#shareable-configs-1
Renamed legacy configurations (Breaking change)
- eslint-plugin-security https://github.com/eslint-community/eslint-plugin-security/blob/c73effd615b337448ca504926a21907fa089f4f4/README.md#flat-config-requires-eslint--v8230
Use
plugin.configs.recommended
for new configuration and'plugin:security/recommended-legacy'
for legacy configuration.
Not supported yet (PR is open)
- eslint-plugin-jsx-a11y https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/pull/891
Maybe
import recommended from 'eslint-plugin-x/recommended'
- typescript-eslint https://github.com/typescript-eslint/typescript-eslint/pull/7935 Maybe new package
Not supported yet
- eslint-plugin-import https://github.com/import-js/eslint-plugin-import/issues/2556
- eslint-plugin-markdown https://github.com/eslint/eslint-plugin-markdown/issues/231
- eslint-plugin-eslint-comments
- eslint-plugin-promise https://github.com/eslint-community/eslint-plugin-promise/issues/449
- eslint-plugin-vue https://github.com/vuejs/eslint-plugin-vue/issues/1291
Unorganized notes
It looks like eslint-config-standard has dropped support for legacy configurations. https://github.com/standard/eslint-config-standard
Note: @typescript-eslint is using a new package because we have both the plugin and the parser. It does also help us out as we don't even need to think about the problem cos it comes for free heh.
The advice from upstream is the breaking change approach - though I don't like it, personally as it's making second class citizens of users not on flat configs.
There's no specific reason that you need to make it available on the .config
export of your package. You could also do it as a different exported name, or a separate path (eslint-plugin-regexp/config
).
Unicorn didn't use /config
because this requires exports
to be added in package.json, since it should support both import and require.