Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Export flat configs from root entry point #135

Closed
wants to merge 6 commits into from

Conversation

nix6839
Copy link
Contributor

@nix6839 nix6839 commented Apr 4, 2024

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
Copy link
Collaborator

joshwilsonvu commented Apr 14, 2024

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.

  • typescript-eslint: I see that they export configs from the root entry point, but to do that they had to make a new typescript-eslint package; they couldn't support flat config in @typescript-eslint/eslint-plugin without breaking legacy config. I'm not willing to support a new package.
  • eslint-plugin-react: Looks like they export shared configs from /configs/* paths, just like this plugin is doing today.
  • eslint-plugin-prettier: Also export shared configs from /configs/* paths
  • eslint-plugin-astro: Works similarly to what you've proposed.
  • eslint-plugin-vue: Works similarly to what you've proposed.
  • eslint-plugin-svelte: Similar to what you've proposed, with a hack to make the circular reference work.
  • Do you have any more examples you'd like to share?

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
Copy link
Contributor Author

nix6839 commented Apr 14, 2024

@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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants