Test 'oxlint' in the Authoring MFE

[bradenmacdonald]

I'd like us to consider replacing eslint with oxlint across all Open edX frontend repos. This ticket is to track work to test Oxlint in this MFE's codebase. See the related PRs for findings.

PR to test oxlint in this repo on a trial basis: #2847

Issues found from testing

• 104 missing/spurious await statements in test code test: fix test code improperly using/missing 'await' #2560
• 50+ additional missing/spurious await statements chore: fix incorrect or missing 'await' usages #2592
• 8 redundant declarations of undefined type on optional parameters chore: fix unnecessary 'undefined' types #2589
• 110 unused error variables chore: don't name unused errors in catch expressions #2591
• 15 questionable .toString() usages chore: fix no-base-to-string #2597
• 2 very bad usages of eval() ! Fix parsing of OLX "correct" attribute #2848
• 2 nullish coalescing operators used pointlessly chore: clean up ValidationResult for NumericalInput problems #2849
• 52 type issues of various severity Fix 52 various type warnings and problems found by oxlint #2850

Private ref MNG-4763

[bradenmacdonald]

@arbrandes @brian-smith-tcril I'd like to start using oxlint (alongside eslint for now) in the Authoring MFE, as so far in my testing it's found lots of substantial issues (especially missed await usages and type problems) that eslint has missed, and it's lightning fast. Any objections or comments?

[arbrandes]

Looking over the PRs, it does look like there's significant value in it, though it obviously means it'll take some clean-up work to start using. No objections to the experiment, in any case.

My question is only: what are the risks of eventually dropping eslint? In other words, how do we get oxlint to catch a superset of the problems eslint catches now, instead of just catching a different set?