Use typescript-eslint's recommended configs as a starting base

[JoshuaKGoldberg]

👋 Hi! I'm one of the typescript-eslint maintainers, and I see the custom list of rules in /packages/config/src/eslint/typescript.js. It's great to be so intentional about the lint settings.

But - there are also shared configs that come with the typescript-eslint plugin: https://typescript-eslint.io/users/configs. Those configs -especially recommended and recommended-type-checked- enable the commonly useful rules that most projects generally find useful and not too opinionated.

Our recommendation is that projects start with those presets and add customizations on top of them as needed. This has a few benefits:

• Your configs get much smaller, as there are a lot of built-in rules that are roughly always good to enable
  • Of the 19 enabled rules in typescript.js, 12 have the same options as recommendedTypeChecked.
• You get updates to configs as they change over time, especially for new rules added
• You get a more similar config to how much of the ecosystem behaves
• For us, we get valuable feedback from you on how rules feel, and which should be added/removed from the configs

Specifically, those repeated rules are...

• method-signature-style
• no-duplicate-enum-values
• no-extra-non-null-assertion
• no-for-in-array
• no-misused-new
• no-namespace
• no-non-null-asserted-optional-chain
• no-unnecessary-type-assertion
• prefer-as-const
• prefer-for-of
• require-await
• triple-slash-reference

Proposal: would you be open to switching eslint-config to be based on tseslint.configs.recommendedTypeChecked and tseslint.configs.stylisticTypeChecked?

If it helps, I'd be happy to drive this work forward myself! It directly contributes to typescript-eslint/typescript-eslint#9141, which I'm working on now to prep for our v8 release.

[JoshuaKGoldberg]

For reused configs like this, a common rollout strategy I default to is:

1. Make the change in this repo, keeping any intentional overrides that differ from the shared configs (e.g. array-type being generics)
2. For each downstream repo, send a PR that onboards to this repo's new version, and for each newly reporting rule:
   • If the rule is easy to --fix without changing runtime behavior, do so in that PR
   • Otherwise, disable that rule in the repo's ESLint config with a // TODO to investigate enabling it later