ESLint 9 Migration

Open
  • Is something wrong?
#3,863 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Stale
Tech stack
eslint, nodejs, typescript
Domain
ci-cd, tooling

Research direction

Read the ESLint migration guide, then compare .eslintrc.json and .eslintignore with the requested eslint.config.js and eslint.ignores.js files. Run the linting checks and tests after the migration, and resolve or intentionally configure the listed findings so the gts v7 upgrade is unblocked and CI passes.

Written by the indexing model from the issue text.

Description

size: m type: process

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.

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.

Dominant language
TypeScript
Stars
12.3k
Forks
2k
Avg merge
3d 10h
Merged PRs (30d)
9

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from googleapis/google-api-nodejs-client

All issues in googleapis/google-api-nodejs-client

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.