Update eslint to v9

[henrymercer]

This PR updates eslint to v9. It is too early to update to v10 since some of our linter plugins don't yet have support.

The eslint config file has changed substantially due to converting to flat config and changes to upstream plugins. I have attempted to ensure that the rules we are running are the same, and note that there is only one change to disable directives, which is to remove a while (true) statement that is no longer flagged by the no constant condition linting rule. However this PR would benefit from a careful look at this config file.

I checked import/no-cycle manually, since this has caught user-visible issues for us in the past. Strangely I could not get import/no-cycle to work with eslint v9. It ran, but did not detect an example import cycle. I have replaced it by import-x/no-cycle, but it's still odd to me that this didn't work initially.

Risk assessment

For internal use only. Please select the risk level of this change:

• Low risk: Changes are fully under feature flags, or have been fully tested and validated in pre-production environments and are highly observable, or are documentation or test only.

Which use cases does this change impact?

Environments:

• Testing/None - This change does not impact any CodeQL workflows in production.

How did/will you validate this change?

Going through linter plugins to check rules, confirming other disable directives are still required.

If something goes wrong after this change is released, what are the mitigation and rollback strategies?

• Rollback - Change can only be disabled by rolling back the release or releasing a new version with a fix.

How will you know if something goes wrong after this change is released?

n/a

Are there any special considerations for merging or releasing this change?

• No special considerations - This change can be merged at any time.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Consider adding a changelog entry for this change.
• Confirm the readme and docs have been updated if necessary.

[Copilot]

Pull request overview

This PR upgrades ESLint from v8 to v9, migrating to the new flat config format and updating related linting plugins. This is a development tooling change that does not affect runtime behavior of CodeQL Action workflows.

Changes:

• Updated ESLint from v8.57.1 to v9.39.2 and migrated to flat config (eslint.config.mjs)
• Replaced eslint-plugin-import with eslint-plugin-import-x and removed deprecated plugins
• Removed an eslint-disable directive for no-constant-condition that is no longer needed in ESLint v9

Reviewed changes

Copilot reviewed 15 out of 16 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
package.json	Updated ESLint and linting plugin versions
package-lock.json	Auto-generated lockfile reflecting dependency updates
eslint.config.mjs	Migrated from legacy to flat config format
src/upload-lib.ts	Removed eslint-disable for no-constant-condition (rule now handles while(true) correctly)
lib/*.js	Generated JavaScript files reflecting TypeScript source changes

[mbg]

@henrymercer High-level question here: would we be better off upgrading to an earlier/older minor version of v9 first? Or is the upgrade path from v8->v9 always going to be this flaky?

[sam-robson]

Dug a little and I think this is missing a few rules. compat.extends("eslint:recommended") pulled in all of the eslint:recommended ruleset, whereas the new githubFlatConfigs.recommended grabs from a static list which looks to be based on an older snapshot of eslint:recommended.

These are the missing rules

for-direction
getter-return
no-async-promise-executor
no-constant-binary-expression
no-dupe-else-if
no-empty-static-block
no-import-assign
no-loss-of-precision
no-misleading-character-class
no-new-native-nonconstructor
no-nonoctal-decimal-escape
no-prototype-builtins
no-shadow-restricted-names
no-unsafe-optional-chaining
no-unused-private-class-members
no-useless-backreference
no-useless-catch

I've got a draft PR ready upstream, if you could verify that I'm onto something here!

[henrymercer]

@henrymercer High-level question here: would we be better off upgrading to an earlier/older minor version of v9 first? Or is the upgrade path from v8->v9 always going to be this flaky?

The most confusing aspect of this for me has been the import/no-cycle regression. I still don't know the root cause of that. We could bisect to see if an earlier version solves it, but I'm not sure it's a good use of time now that we have import-x/no-cycle which works.

Dug a little and I think this is missing a few rules. compat.extends("eslint:recommended") pulled in all of the eslint:recommended ruleset, whereas the new githubFlatConfigs.recommended grabs from a static list which looks to be based on an older snapshot of eslint:recommended.

Thanks @sam-robson, this is a great point. I thought that the GitHub ruleset extends eslint/recommended but that's not quite true.

typescript-eslint disables some of the standard eslint rules due to a couple of reasons, e.g. the rule is already checked by the TypeScript compiler, or the rule is replaced by a more precise TypeScript-specific one. So I don't think we necessarily want to have all the eslint recommended rules enabled. But we can enable both js.configs.recommended and tseslint.configs.recommendedTypeChecked to make sure we're getting all the eslint recommended rules that aren't explicitly disabled by typescript-eslint.

I'm not sure whether the upstream githubFlatConfigs.recommended plugin has gone through a process of disabling certain rules for similar reasons. However it seems valid that there's a risk that new rules slip through the cracks if the pattern is to enable each rule explicitly. So some rules we would want may indeed be missing.