solidjs-community / eslint-plugin-solid

Solid-specific linting rules for ESLint.
MIT License
206 stars 24 forks source link

Export flat configs from root entry point #135

Closed nix6839 closed 2 months ago

nix6839 commented 3 months ago

As described here, most other plugins that support flat configs export their flat configs from the root entry point. Therefore, to avoid confusion among users, this plugin also exports its flat configs from the root entry point.

Accordingly, I updated the README and deprecated the previous entry points.

joshwilsonvu commented 2 months ago

Hi, thanks for putting this together. I'd like to dig into the idea that "most plugins export their flat configs from the root entry point" a little bit more.

All this to say, I'm not certain that a true standard has emerged about whether to use /configs/* or to use plugin.configs['flat/*'] from the root. Yes, it's the most common option above, but it's not what the most popular plugins do.

My personal opinion is that plugins.configs['flat/*'] will not age well. If flat config is to eventually become the new standard, it will start to feel strange to prefix each shared config with flat/. Importing shared configs from /configs/* feels more natural to me. Perhaps the plan is to eventually deprecate the legacy configs and remove the flat/ prefix from the flat configs, but that feels like an unnecessary breaking change that could be avoided.

I do feel like there's a compromise position. I'll plan to keep the recommendation the same, but will add 'flat/*' configs to the legacy plugin object, like:

const pluginLegacy = {
  rules: plugin.rules,
  configs: [
    recommended: { /* ... */ },
    typescript: { /* ... */ },
    'flat/recommended': recommendedConfig,
    'flat/typescript': typescriptConfig,
}
export = pluginLegacy;

and add a note that the flat configs are available at require('eslint-plugin-solid').configs['flat/*'] for those who prefer that. I hope this solution that doesn't require type casting, reworking legacy config, and adding deprecations will work for you. Thank you again for putting together a PR!

nix6839 commented 2 months ago

@joshwilsonvu Can you handle these two commits as well?:

If it's too difficult, I'll create a separate PR. Please let me know your thoughts :)