Upgrade eslint to v10

[jjspace]

ESLint v10 was recently released. They have a nice doc for migration here: https://eslint.org/docs/latest/use/migrate-to-10.0.0

Most notably for us they added new defaults for the recommended eslint/js rules which is used "upstream" in our cesium-eslint-config

Three new rules have been enabled in eslint:recommended:

• no-unassigned-vars
• no-useless-assignment
• preserve-caught-error

Turning these on surfaces 680+ errors in CesiumJS. I took a cursory glance at a handful of them and I do think these are rules we want turned on but it will be a large tedious PR to turn on.
I've opened a preliminary config update for when someone is ready to tackle this: CesiumGS/eslint-config-cesium#11

Regardless of the rule changes the eslint-plugin-react-hooks that we use for Sandcastle files is not compatible with v10 yet anyway: facebook/react#35758

[javagl]

Right now there's over 680 of them

I think that there was a CI build where they accidentally appeared...? Maybe there's a known link, or I could investigate this myself, but I'm a bit curious how they are distributed among these three classes, and how many of them could be fixed "mechanically" (maybe by some RegEx-replace of var x; to var x = undefined; or whatnot). In any case, the rules sound like there should be zero close-to-zero chance that the changes will "break" anything or cause regressions. (Just a gut feeling for now...)

[jjspace]

I'm a bit curious how they are distributed among these three classes

Judging by grep and wc -l

• preserve-caught-error: 3 (These were easy to fix when I first looked into it
• no-useless-assignment: 586
• no-unassigned-vars: 39

When I was looking at them the no-useless-assignment ones were not just a simple regex replace. It seemed like many, maybe all, would need specific analysis about usage. I think no-unassigned-vars is similar, especially for the few instances where it's a variable to be used in the result of a clone or generator function.

(replace of var x; to var x = undefined; won't work because It's not necessary to initialize 'x' to undefined. (no-undef-init))

For example, this line, strafing is never used and triggers the warning error, however the structure stripped of other logic looks like this:

let strafing = false;
if (cameraUnderground) {
  strafing = true;
} else {
  if ([condition]) {
    strafing = true;
  } else {
    strafing = [boolean condition]
  }
}

Yes, at the end of this the initialized value is never used but it's hard to see that. Perfect example of why the rule is useful but not automatible.
Alternatively, this line where the variable is only ever used in a for loop and always assigned another value.

let indices = totalIndices[0];
// ...
for (let k = 0; k < numberOfIndicesArrays; ++k) {
  indices = totalIndices[k];
  // ...
}

the rules sound like there should be zero close-to-zero chance that the changes will "break" anything or cause regressions

I agree that it seems like >95% of cases wouldn't change behavior and the last 5% is just being conservative, I don't think any actually affect things. It will just take time to go through them I think.