[eslint-config] Update TypeScript/ESLint Utilities and Refactor Linting

[D4N14L]

Summary

Bump @typescript-eslint/eslint-plugin and @typescript-eslint/eslint-parser to their respective latest versions. Also refactor the lint plugin to load linter packages asynchronously.

Note that the latest versions of the @typescript-eslint/eslint-parser and @typescript-eslint/eslint-plugin packages are only compatible with >=8.57.0, so the peerDependencies version specified on @rushstack/eslint-config was respectively bumped to ^8.57.0 (since we have not validated with ^9.0.0 yet), and the change was marked as a major bump. Also note that this will break Node 16 compatibility for @rushstack/eslint-config due to broken compatibility in @typescript-eslint/eslint-plugin, and as such I've removed Node 16 testing from Rushstack. Given that it is now over a year out of support, this feels fair.

How it was tested

• Repo-based ESLint projects
• Repo-based TSLint projects
• Added new test projects to continue validation of specific scenarios with older ESLint versions
• Updated existing ESLint test projects to reference the cyclic version of the config to allow for backwards compatibility while still using the latest version of the plugin

Impacted documentation

N/A

[kevin-y-ang]

Hi @D4N14L,

tiktok is currently facing a problem where the typescript-eslint plugin will break if a package tries to upgrade its typescript version. The most straightforward solution is to upgrade the typescript-eslint plugin version along with the the TS version, but tiktok follows rushstack's shared eslint-config model, so typescript-eslint is a dependency of the shared eslint-config rather than a dependency for every package. Upgrading the typescript-eslint version might fix eslint for this 1 package, but it breaks a couple of the 999 other packages that are on an older version of TS.

Basically, our monorepo needs to be support packages that each run a different TS version, while still sharing the same eslint-config (and thus, the same typescript-eslint version?), but because our typescript-eslint version is centralized yet the TS version is decentralized, the former is blocking upgrades to the latter.

I think our best solution is the upgrade to the newest version of typescript-eslint and hope it is backwards compatible. If not, we wait for people to report problems in their CI and and handle each broken package on a case by case basis.

An alternative solution I'm considering is whether it's possible for typescript-eslint to be a peer dependency without compromising on the benefits of a shared eslint config (telemetry, rule governance, standardized CI).

Have you ever faced any similar problems?

[D4N14L]

@kevin-y-ang What do you mean by this?:

the typescript-eslint plugin will break if a package tries to upgrade its typescript version

In what way does it break? Is it the same way that I refer to in this issue? #3021

An alternative solution I'm considering is whether it's possible for typescript-eslint to be a peer dependency without compromising on the benefits of a shared eslint config (telemetry, rule governance, standardized CI).

I don't think this is the right answer. If the issue is that the parser is no longer compatible with the version of TypeScript you're using, you can manually specify the parser that you use and override the one provided by the @rushstack/eslint-config package. This is the same resolution that I provide in #3021 mentioned above.

[kevin-y-ang]

Thank you for the quick and helpful reply. Reading through the issue you linked, I think the solution to the problem we're facing is probably similar.