Why does @nx/angular:library generator produce eslint config files that override base config rules?

[JanPolasek]

@nx/angular:library generator produces eslint configs that first extend the baseConfig but then extend other sets of rules, in case of flat config the order is

  ...baseConfig,
  ...nx.configs["flat/angular"],
  ...nx.configs["flat/angular-template"],

Meaning that by default angular-eslint rules will take precedence over whatever the user wants and has set in their base config.

There has been a related issue for it, #5259, but it's been closed as fixed, I guess because technically the issue asked for NX to override fewer rules, which it does now, but it still overrides some, which to me implies that this behaviour is intentional.

What's the rationale behind overriding the base config rules like that? There are way too many eslint config files in an average nx monorepo, so it makes sense to set the majority of the rules in the base config and then only make the necessary lib-specific changes in the lib-level configs (like component prefixes), so I feel like this default behaviour is highly counter-intuitive.

[Phhansen]

I've had this question pop up internally also so i'll chime in.

I think from the nx side it makes sense to not have the angular specific eslint configs in the root eslint config. Remember that nx is not for angular only and you'll run into monorepos that have both angular and react or other frameworks.

That would mean the root config has to include lint configs for all of the provided frameworks and I assume, (not entirely sure here), that could cause clashes. And also just the fact that it makes no sense to run angular eslint rules in a react lib.

I think that is why each lib has to have those configs, - although it does look very counter-intuitive.

Maybe having several "root" level configs per lib type (so angular.eslint.config.mjsetc) could be the solution, i'm not sure.

[JanPolasek]

I understand that in mixed-framework monorepos there's a need to have separate configs, but even in that case the multiple base config approach is the more ergonomic solution compared to having to edit a 100 eslint.config.mjs files just to change one rule that's supposed to be global for the given framework.

The multiple base config approach could even be handled by the NX generators themselves if an option to override base config path was added