Maybe just config? Cleaner to say & write, and after a year or so most new projects should only/primarily think about flat configs.

the problem with calling it config is that you then have both config and configs exported from the package.

It does make things a little confusing?

Hmm yeah never mind... 🤔 a tough naming situation.

Eh it works fine enough - I added it as is. People will deal with it it's not THAT bad.

Question:
What do we think about making this utility enforce a canonical name for plugins?

For example imagine like:

// eslint.config.js
import * as tseslint from '@typescript-eslint/core';

export default tseslint.config(
  {
    '@typescript-eslint': tseslint.plugin,
    // ...
  },
  {

  },
);

Then within the util we could rewrite all configs so that any references to the plugin use the defined namespace, and we rewrite it with pseudocode like:

for config in configs {
  const pair = config.plugins.entries().find(plugin.value)
  if pair && pair.key !== plugin.key {
    pair.key = plugin.key
    config.rules.keys().replace(`${pair.key}/`, `${plugin.key}/`)
  }
}

Pros: fixes the "multiple namespace problem"
Cons: rewrites user configs, includes some complexity.

WDYT?

Alternate forms:

• more explicit object form like config({ plugins: { ... }, configs: [ ... ] })
• a util function form like config.withPlugins({ ..plugins.. })(..configs[]) (where config(..configs[]) acts without explicit enforcement)

I like the idea at first glance, but suspect it should be done in a follow-up issue so that the ESLint folks can provide input too.

Based on the discussions we've had (eslint/eslint#17766) - this is fully intended behaviour and it doesn't look like they intend to change that?

Oh I mean more on input for direction of the checking.

Plus splitting it out will make it easier to reference it when complaining about the name aliasing being allowed 😄

nrwl/nx#21405

[Docs] This should be added to sidebar.base.js so it shows up & has a sidebar.

UGH. We should automate this somehow.

[Style] If they're unused, why bother including them?

Here, and the unused import above?

cos it sets things up to have a consistent API shape - which is nice in case we do change things in future.

I.e. it means we can blindly write

configs: {
    all: allConfig(plugin, parser),
    base: baseConfig(plugin, parser),
    disableTypeChecked: disableTypeCheckedConfig(plugin, parser),
    eslintRecommended: eslintRecommendedConfig(plugin, parser),
    recommended: recommendedConfig(plugin, parser),
    recommendedTypeChecked: recommendedTypeCheckedConfig(plugin, parser),
    strict: strictConfig(plugin, parser),
    strictTypeChecked: strictTypeCheckedConfig(plugin, parser),
    stylistic: stylisticConfig(plugin, parser),
    stylisticTypeChecked: stylisticTypeCheckedConfig(plugin, parser),
}

rather than having to maintain which ones get args and which don't.

[Non-Actionable] Heh, good catch...

DAMN YOU AMERICANS SPELLING THINGS WRONG

IT'S NOT OUR FAULT WE DON'T HAVE AUSTRALIAN COFFEE