Consider updating to ECMA version 2022

[javagl]

(Originally brought up in #12567 (comment) )

The eslint-config-cesium configuration for browsers currently sets ecmaVersion: 2020. I think that it could make sense to update this to ecmaVersion: 2021 or 2022.

With this version, the ESlint rule "logical-assignment-operators": ["error", "always"], could be enabled. This would complain about thousands of places where the defaultValue was recently changed, suggesting to change things like
options.contextOptions.webgl = options.contextOptions.webgl ?? {};
to
options.contextOptions.webgl ??= {};
but I think this would be nice, because it could tremendously decrease duplication.

Other places are then about the 'destroy' pattern, where
primitive = primitive && !primitive.isDestroyed() && primitive.destroy();
would become
primitive &&= !primitive.isDestroyed() && primitive.destroy();
which could also be a nice improvement.

[javagl]

Based on the comment from @jjhembd at #13101 (comment) , I updated the title of this issue. I'll schedule another update of the title of this issue for December 2026.

[jjspace]

My go-to compatability source for JS is this wonderful table https://compat-table.github.io/compat-table/es2016plus/
I also rely pretty strongly on MDN's Baseline system. I think we should probably only be using things that are truly baseline instead of "newly available" and the cutoff for that is 2.5 years

I'm personally not a huge fan of the syntax options.contextOptions.webgl ??= {};. I find it hard to read but maybe that's just a lack of experience with it. primitive &&= !primitive.isDestroyed() && primitive.destroy(); is even more confusing imo...

Regardless I do think it's time to update for some of the other features. I've specifically wanted numeric separators, like 10_000_000, for the many large numbers we have dotted around, especially in tests.
Static, instance and private class fields would be really awesome too as we look at the class conversions needed for the TS transition.

[javagl]

Just to have the connection: The specific case that is revolving around destroy might become obsolete (or less cryptic) if #12266 is addressed.

[donmccurdy]

Quick heads up (based on @jjspace's comment in #13218), as we're running type checks (tsc) on some source files, it would also be good to keep ES20XX versions in sync between the tsconfig.json compilerOptions.target field and the ESLint configuration. The compilerOptions.module field is a bit different, I'm not sure if that needs to match or not.

Currently tsconfig.json uses ES2022, but that was mostly an arbitrary choice on my part. There's a bit of newer syntax in the scripts/ folder that we'd need to roll back if we want TS to check against ES2020 syntax, which I think probably isn't necessary if we want to update anyway.

[jjspace]

FWIW I did switch to this along with the update to eslint v10 in CesiumGS/eslint-config-cesium#11 but it might be worth splitting that PR if we don't want to handle those errors yet

[donmccurdy]

I don't expect CesiumGS/eslint-config-cesium#11 will cause errors with the scripts/ type checking — they only run into errors if we downgrade tsconfig.json from ES2022 to ES2020.

[jjspace]

Sorry, I meant the errors introduced by the new eslint rules in v10. Right now there's over 680 of them which may be a slight blocker to upgrading eslint itself