[Fix] export flat configs from plugin root and fix flat config crash #3694
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3694 +/- ##
=======================================
Coverage 97.76% 97.76%
=======================================
Files 133 133
Lines 9471 9475 +4
Branches 3472 3472
=======================================
+ Hits 9259 9263 +4
Misses 212 212 ☔ 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? |
bradzacher
force-pushed
the
3693-flat-config-crash
branch
from
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. |
ljharb
force-pushed
the
3693-flat-config-crash
branch
from
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) |
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.