ESLint 9 Migration

[quirogas]

The Pull Request chore(deps): update dependency gts to v7 #3856 is currently blocked due to CI failures.

The core of the issue is that gts v7 upgrades the linter to ESLint v9, which introduces a breaking change by switching to a new "Flat Config" system. The existing configuration infrastructure is incompatible with this new version.

Resolving this requires a two-step approach.

---

Step 1: Infrastructure Migration (ESLint 9 Flat Config)

ESLint 9 drops support for .eslintrc.json and .eslintignore. The project must migrate to eslint.config.js and eslint.ignores.js.

Findings & Reference

In Flat Config, ignore patterns are strictly relative to the configuration file, and global variables (like process or module in Node.js) must be explicitly declared in the config for JavaScript files.

• Reference: ESLint Migration Guide - Ignoring Files

Required Technical Changes

1. Create eslint.ignores.js: Export the array of ignore patterns (migrated from .eslintignore).
2. Create eslint.config.js:
   • Extend gts.
   • Import ignore patterns.
   • Declare globals.node for **/*.js files to prevent no-undef errors.
3. Clean up: Delete .eslintrc.json and .eslintignore.

---

Step 2: Code Compliance (New Linting Findings)

After migrating to ESLint v9, the new linter identifies several violations in the existing codebase that were previously ignored or not checked with the same intensity. We need to determine the best path forward for these findings, whether is to mute the findings, fix the findings, or come up with a hybrid approach.

Findings

The following rules are failing across multiple files (many of which are autogenerated):

• @typescript-eslint/no-unused-vars
• @typescript-eslint/no-explicit-any
• @typescript-eslint/no-unused-expressions

Open Questions:

1. Mute the findings (Short-term): Should we disable these rules in eslint.config.js to unblock the gts v7 upgrade? This would maintain the current state of the codebase while adopting the new tooling.
2. Fix the findings (Long-term): Since many of these files are autogenerated, should we block the upgrade until the generator logic is updated to produce compliant code?
3. Hybrid Approach: Mute them now but create a follow-up task to address the generator's output?

NOTE: muting these rules in the new eslint.config.js allowed all linting checks and tests to pass successfully when testing this changes locally.