@ljharb Since#3879 is blocked, I tried to fix the typing issue from a different angle: creating a new flatConfigs object outside of the originalconfigs. This eventually will become a breaking change but not at the moment, as the originalconfigs.flat is still kept and only marked as deprecated through JSDoc.

If we run out of ideas on#3879, maybe we can go with this one?

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.71%. Comparing base(e6b5b41) to head(cd3665a).
Report is 13 commits behind head on master.

@@            Coverage Diff             @@##           master    #3882      +/-   ##==========================================+ Coverage   97.66%   97.71%   +0.04%==========================================  Files         136      133       -3       Lines        9978     9971       -7       Branches     3703     3703              ==========================================- Hits         9745     9743       -2+ Misses        233      228       -5

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report?Share it here.

I agree this is semver-minor, but I have no desire to go with that model. I want a single configs object with eslintrc configs, and aflat on it that holds all the flat configs. If the only unsolvable issue with that is that you might need to useNonNullable<> or!, I think that's acceptable (i don't think it's unsolvable, to be clear, but i'm not willing to use what i think is a worse object layout)

I agree this is semver-minor, but I have no desire to go with that model. I want a single configs object with eslintrc configs, and aflat on it that holds all the flat configs. If the only unsolvable issue with that is that you might need to useNonNullable<> or!, I think that's acceptable (i don't think it's unsolvable, to be clear, but i'm not willing to use what i think is a worse object layout)

Yeah you are right, I just checked and found out ESLint supportsts config since v9.9.0, before thatNonNullable<> or! are not an option, I guess it is not a big deal then compared to using// @ts-expect-error in thejs config.

And just curious, you are also the main maintainer ofeslint-plugin-import andeslint-plugin-jsx-a11y, why is this plugin choosing this layout while the other two using the layout similar to the PR? TBH this is the only plugin among the few popular ones I used that use this layout, others either have flatConfigs as a separate object, or have the flat configs in the same level as the legacy configs (all inside the same configs object) and prefix the name withflat.

It's a fair point that they're not all the same; this, however, is what i would have preferred to do on the other two, i just didn't notice the difference.

Prefixing means you can't programmatically compare them, for example - munging string names isn't clean at all. A separate object, at least, is more reasonable, butconfigs is the only property under which i'd expect to find configs.