This fixes the subset of ESLint violations over public/mods/gui/common that are not automatically fixable by ESLint (e.g. not purely
stylistic/deterministic). Fixes for those stylistics issues I'll commit separately as they're much easier to review that way and would only add noise this diff of manually made changes.
gui/common/color.js:
- Unexpected chained assignment. [no-multi-assign]
At h = s = 0;.
At r = g = b = l;.
Fixed by assigning each one separately.
- Expected a default case. [default-case]
At switch (max) in rgbToHsl().
Added an inline ignore for now, as this would require a non-trivial change to fix and might not be an issue.
Can be revisited later in a Trac ticket, or by grepping for "eslint-disable".
gui/common/functions_utility.js:
- Empty catch statement. [empty-block] https://eslint.org/docs/rules/no-empty
At catch (e) {}.
Document as intentional with an inline comment.
gui/common/gamedescription.js and gui/common/settings.js:
- Variable already declared in the upper scope. [no-shadow]
At difficulty = ….TriggerDifficulties.find(difficulty => ….
At victoryCondition = ….VictoryConditions.find(victoryCondition => …
Use a different name for the inner and outer scope.
gui/common/tab_buttons.js:
- Variable already declared in the upper scope. [no-shadow]
At button.onPress = (category => function() { onPress(category); })(+category);
This was a bit of a mess. It created and self-invoking arrow function that returns a regular function - all whilst inside a for-loop. Creating functions inside a loop is a dangerous anti-pattern because the block scope of the for-loop does not close over the function scope, which means most behaviours you'd expect from such a function are not actually available. All created functions would see the same single state after the loop iterations.
Make the effectively-local variable a real local variable, and assign onPress as an arrow function instead.