-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
[New] export flat configs from plugin root and fix flat config crash #3694
Conversation
Co-authored-by: Brad Zacher <brad.zacher@gmail.com> Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3694 +/- ##
==========================================
+ Coverage 94.28% 97.76% +3.47%
==========================================
Files 134 133 -1
Lines 9613 9475 -138
Branches 3486 3472 -14
==========================================
+ Hits 9064 9263 +199
+ Misses 549 212 -337 ☔ View full report in Codecov by Sentry. |
hmm - i definitely prefer deep imports; barrel files/manifest exports cause all sorts of problems. how would the refactor work to have flat configs not be at the root? |
f826040
to
674cd1f
Compare
An example of a plugin that goes your deep import approach is https://github.com/eslint-community/eslint-plugin-eslint-plugin/ They define the flat configs as a function of the legacy configs. EG const plugin = require('../index');
module.exports = {
plugins: { react: plugin },
rules: plugin.configs.recommended.rules,
}; But their usecase is a bit simpler as it doesn't need to worry about language options etc. |
674cd1f
to
eb0c123
Compare
I've rebased this; i'm still hopeful for a way to have the root be the current legacy config, in particular to avoid a breaking change. |
Any update on this? This plugin is unusable with Airbnb config until this is pulled |
@jakec-dev the airbnb config doesn't use flat config, so it should be perfectly usable if you use a compatible version of eslint (not 9, yet) and the default config format of the supported eslint versions (eslintrc) |
It isn't a problem for either of the two config systems (eslintrc and flat) to include both config formats in |
On the other hand, if you prefer deep imports, a solution could be to invert 17858be: move rule configs and parserOptions back to |
Also relevant: eslint/eslint#18095 |
I vastly prefer deep imports, for both eslintrc and flat. If we can use those, and ensure no breakage for existing eslintrc users, then that sounds like a great solution to get this over the line. |
eslintrc config system doesn't provide a way for plugins to export configs other than under the As for flat configs, this is doable as @bradzacher suggested in #3694 (comment). Technically, it could be implemented as suggested in #3694 (comment). |
Sounds great, let's do that :-) If you drop a link to a sha or branch here, i can pull it into this PR |
Here's the branch: https://github.com/mdjermanovic/eslint-plugin-react/tree/fix-flat-configs
I'm not sure why |
It was set that way because eslint threw when it was enumerable - i forget whether it threw with eslintrc, or with flat config, but making it nonenumerable hid it from one and allowed the other to read it. |
eb0c123
to
2692c07
Compare
@mdjermanovic hm, those two commits are on top of master, not this PR, and there's a conflict. I've rebased this PR; can you stack your commits on top of it, and then I can pull them in? |
@ljharb to clarify, do you want eslint-plugin-react to provide two ways to use its flat configs? 1st: const reactRecommended = require('eslint-plugin-react/configs/recommended');
module.exports = [
reactRecommended
]; 2nd: const reactPlugin = require('eslint-plugin-react');
module.exports = [
reactPlugin.configs['flat/recommended']
]; |
I’m comfortable with that, as long as it doesn’t introduce cycles - but it’d also be sufficient to only have the deep import way (but it should say “flat” somewhere in there) |
Here's a branch on top of this PR. It keeps flat configs in plugin root (those added in this PR), fixes existing flat configs intended for deep imports, and adds tests for both: https://github.com/mdjermanovic/eslint-plugin-react/tree/fix-deep-flat-configs |
fixes #3693
This PR exposes the flat configs at the root of the plugin:
The
flat/
prefix is an approach a number of plugins are taking to enable supporting both styles at the top-level.This was the easiest way to set things up so that the plugin reference was consistent across the root and all configs.
I'm open to a different approach to fixing the issue - for example if you want to ensure the
config/
exports all work as well - it's just going to be a much larger refactor to make that work because we need to restructure the configs so there isn't a cyclic dependency between the configs and the plugin.Personally I'm of the opinion that this "everything from the root" approach offers better DevX compared to forcing users to separately import the configs. It's a stylistic thing though - up to you really.