This is the default for eslint 9 and will be the only option
in eslint 10.

See https://eslint.org/docs/latest/use/configure/migration-guide

There's apparently a bug with the globals release we had
automatically installed and eslint flat config, so just updated
to the latest version manually since that one is fixed.

For some reason (.mjs differences?) these two files
had eslint issues that were not reported with the old config.

Rather than having a convoluted system to check unfixed rules,
this just has them apply to all files, and only selectively
disables them for files we know to be unfixed.
This helps us not introduce more issues in the meantime.
I did generalize a bit for release-editor and similar folders
where we don't expect to fix the files but convert them entirely,
so there's no point fixing them file by file.

For some reason (.mjs differences?) these files
had eslint issues that were not reported with the old config.

This is a new recommended rule in eslint 9:
https://eslint.org/docs/latest/use/migrate-to-9.0.0

Most stylistic rules have been split from the eslint package
and moved to a separate one - the eslint ones still work but
are officially deprecated, so we might as well update before
they break.
I'll move these to a separate block in a second commit to make it easier to review.

https://eslint.style/rules/js/arrow-spacing

https://eslint.style/rules/js/dot-location

We consistently use the property dot location position.
Especially given how that's not even the eslint default,
it seems worth enforcing with a rule.

https://eslint.style/rules/js/generator-star-spacing

We consistently use the 'after' style.
Especially given how that's not even the eslint default,
it seems worth enforcing with a rule.

This was listed under errors, but it's a stylistic rule.

This was listed under best practices, but it's a stylistic rule.

This was listed under best practices, but it's a stylistic rule.

This was listed under ECMAScript 6, but it's a stylistic rule.

This was listed under ECMAScript 6, but it's a stylistic rule.

https://eslint.style/rules/js/yield-star-spacing

We were inconsistent here, but I talked to mwiencek and we both
prefer the 'after' default.

Most stylistic React rules have been split from the react package
and moved to a separate one - the react ones still work but
are officially deprecated, so we might as well update before
they break.
I'll move these to a separate block in a second commit to make it easier to review.

https://eslint.style/rules/jsx/jsx-curly-newline

We were inconsistent here, but not horribly so.
Auto --fix'ed 38 issues.

The old rule is deprecated in 9.0.0 and replaced with
the new one, which is already available, so making
the change in preparation.

We don't have any clashes with the new rule, it seems.

https://eslint.org/docs/latest/rules/array-callback-return

https://eslint.org/docs/latest/rules/no-unreachable-loop

We already intentionally clarified we did not use a lot of rules.
This is the first step into making that more generalized,
plus it applies a bunch of newer rules we already followed
but might actually want to enforce.

This was fairly arbitrary anyway, and this makes it easier
to compare with the eslint rule docs.

https://eslint.org/docs/latest/rules/default-case-last

We have one use which kinda makes sense, but is also confusing.
There's no reason we cannot put case 0 and default last, and
we don't actually have a type 0,
so it's already a default anyway.

https://eslint.org/docs/latest/rules/default-param-last

We have three cases where it seems to be needed to flout the rule
(two seem to just be because the rule doesn't understand that
? means the param is optional anyway).
Added eslint-disable comments for those.

https://eslint.org/docs/latest/rules/no-case-declarations

None of our few hits seem intentional (they all end in break;),
so just added brackets as suggested by the rule.

https://eslint.org/docs/latest/rules/no-useless-concat

The two places where we hit this do not seem more clear for having
two separate strings.

https://eslint.org/docs/latest/rules/no-useless-escape

We had a somewhat embarrassing amount of hits here,
including a few where we were escaping *too little*.

https://eslint.org/docs/latest/rules/no-redeclare

We had one hit, where the redeclared param seems useless
anyway.

https://eslint.org/docs/latest/rules/no-return-assign

Couple of places where we didn't want to return anything
anyway, so just doing { }.
In URLCleanup, all we gained was one line, so eh.

https://eslint.org/docs/latest/rules/no-loop-func

The only place where we hit this is actually fine
because it's executed immediately but in general this is
a good thing to keep in mind.

https://eslint.org/docs/latest/rules/logical-assignment-operators

We weren't using these at all, but it actually seems quite nice
and avoids a lot of repetition.

https://eslint.org/docs/latest/rules/no-implicit-coercion

In many cases, especially when we have Flow types, it's
a lot better to just do the actual check that makes sense
based on the data instead of having boolean coercion.
For places where we don't have Flow, or coercion to
string or number, it's probably sensible to just do
the coercion explicitly.

https://eslint.org/docs/latest/rules/func-style

By far most of our (non-arrow) functions were already using
the declaration style, so this just standardises the last few cases
for consistency.

https://eslint.org/docs/latest/rules/no-useless-return

We had one case (my own fault).

https://eslint.org/docs/latest/rules/prefer-object-spread

https://eslint.org/docs/latest/rules/object-shorthand

All --fix'ed. In TagEditor Flow was worried but it seems to be
a false positive for object-this-reference.

https://eslint.org/docs/latest/rules/prefer-object-has-own

Using this means we no longer seem to have a need
for our own function hasOwnProp.

https://eslint.org/docs/latest/rules/prefer-regex-literals

Almost all changes are in the match section of URLCleanup.
Honestly, I'm not sure what the original reason was for that part
to be a string regex - there was a slight benefit, in that it allowed
having the regex in several lines to make it a bit more readable.
That said, there were so many cases where we were over-escaping
and, a lot worse, a bunch where we were *under-escaping*, leading
to actually incorrect regexes.
This way is a lot easier to get the escapes right.

https://eslint.org/docs/latest/rules/prefer-rest-params

https://eslint.org/docs/latest/rules/prefer-spread

GuessCase/Main was messy enough that this refactors it a bit
to make Flow less angry.

https://eslint.org/docs/latest/rules/require-await

This mostly hit cases where we didn't actually need async
since they return Promises. There was one case where we needed to wrap some returns
in Promise wrappers, but that's about it.

We don't need this to remind us to use strict, but it did warn me
of one unnecessary use of it! So worth having on for that.

https://eslint.org/docs/latest/rules/yoda

Three cases of this we had, a bit stupid it looked.

This adds some rules that seem useful as warn, and lists all others
as off, so we know we looked at them and decided against them
rather than not having decided yet.

https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-useless-path-segments.md

We had a fair amount of these!

https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-extraneous-dependencies.md

We only had one of this, defined in selenium.mjs... which seems
to be pretty useless anyway, so just replacing it with a simpler
option (we shouldn't really care if the message is '' or undefined).

https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/prefer-default-export.md

There's no good reason anymore to not have a default export
for manifest (we used to have two exports but we no longer do).
Other files were a lot more trivial.
tableColumns is clearly meant as something that might eventually
have more exports, and so is report/constants,
so I disabled the rule there. Same for i18n/history.

This activates a few more rules and specifies the ones we do not want
are intentionally off. There's a few rules that do not currently
work with a flat config setup but we probably do want;
I commented those out for now.

https://eslint.style/rules/js/function-call-argument-newline

https://eslint.style/rules/js/no-mixed-operators

This activates a few more rules and specifies the ones we do not want
are intentionally off.

This activates a few more rules and specifies the ones we do not want
are intentionally off.

https://github.com/jsx-eslint/eslint-plugin-react/blob/master/docs/rules/jsx-fragments.md

https://github.com/jsx-eslint/eslint-plugin-react/blob/master/docs/rules/jsx-no-useless-fragment.md

https://github.com/jsx-eslint/eslint-plugin-react/blob/master/docs/rules/no-unstable-nested-components
.md

This activates a few more rules and specifies the ones we do not want
are intentionally off.

https://github.com/flow-typed/eslint-plugin-ft-flow?tab=readme-ov-file#enforce-suppression-code

Our Multiselect typing is a horrible mess that we will fix
in a separate PR, for now this disables the rule there
since we have to ignore *four* Flow rules for them.

https://github.com/flow-typed/eslint-plugin-ft-flow?tab=readme-ov-file#no-types-missing-file-annotation

https://github.com/flow-typed/eslint-plugin-ft-flow?tab=readme-ov-file#object-type-curly-spacing

https://github.com/flow-typed/eslint-plugin-ft-flow?tab=readme-ov-file#no-internal-flow-type

We were using these to avoid importing React all the time,
but a recent Flow version made it so that it's no longer needed,
so we might as well return to the standard types.

This activates a few more rules and specifies the ones we do not want
are intentionally off.

https://github.com/flow-typed/eslint-plugin-ft-flow?tab=readme-ov-file#use-read-only-spread

https://github.com/facebook/flow/tree/main/packages/eslint-plugin-fb-flow#use-exact-by-default-object-type

This activates a few more rules and specifies the ones we do not want
are intentionally off.

https://github.com/eslint-stylistic/eslint-stylistic/releases/tag/v2.0.0

https://github.com/eslint-stylistic/eslint-stylistic/releases/tag/v2.1.0

This fixes a bug where flow annotations were not seen
when in multiline comments - so most of our files...

A lot of issues came up that were previously hidden for
'no-flow-suppressions-in-strict-files'.

https://github.com/eslint-stylistic/eslint-stylistic/releases/tag/v2.2.0

https://github.com/eslint-stylistic/eslint-stylistic/releases/tag/v2.2.1

https://github.com/eslint-stylistic/eslint-stylistic/releases/tag/v2.2.2

https://github.com/eslint-stylistic/eslint-stylistic/releases/tag/v2.3.0

None of the new options seem preferable, so not using them.

2.3.0 deprecates jsx-indent because indent from @stylistic/js
does all the same things by now.