☂️ Clean up eslint usage - remove 'legacyCode' ignoring

☂️ This is an epic / umbrella issue We expect this to be done in multiple PRs as it’s better to change a few pages at a time, please reference this issue in any new PRs

Description

• As part of the ongoing improvements to the Wagtail frontend codebase the plan is to ensure that new code and existing code can adopt the baseline eslint rules.
• The goal is to incrementally clean up eslint rules, with mostly adopting the rules provided by https://github.com/wagtail/eslint-config-wagtail and adjusting that repo if needed.
• This is so that newer code can be written without ignoring too much and to get to the bottom of which rules are not really ‘legacy’ rules.

Approach

Part 1 - Remove unnecessary rules or rules that are formatting fixes only

• https://github.com/wagtail/wagtail/pull/8734
• https://github.com/wagtail/wagtail/pull/8736
• https://github.com/wagtail/wagtail/pull/8737

Part 2 - Move some rules to global ignore as they really do not suit existing code approaches

• https://github.com/wagtail/wagtail/pull/8738
• Note: May want to add issues/PRs to adopt some of the global rules in eslint-wagtail
• May be others

Part 3 - Assess small fixes when removing linting rules

• There may be some rules that are quick wins and only require one or two changes/fixes to files

Part 4 - Try to scope overrides rules: legacyCode, to specific files

• There may be rules ignored via legacyCode that are harder to fix by only really touch one or two files, try to ignore these explicitly instead of whole folders like entrypoints/utils

Links

• https://github.com/wagtail/wagtail/discussions/7689

[nutjob4life]

@nutjob4life - please ignore this sorry.

I was just studying up on eslint and was getting ready to dive in! 😝

Oh well, another time! 😁

[lb-]

@Lovelyfin00 there is one small chunk left, it would be great if you could pick this up if you get the chance this week.

Step 1 - remove legacy rules

This whole block can be removed now.

// Rules which have been enforced in configuration upgrades and flag issues in existing code.
// We need to consider whether to disable those rules permanently, or fix the issues.
const legacyCode = {
  'default-param-last': 'off',
  'no-continue': 'off',
  'no-else-return': 'off',
  'no-restricted-syntax': 'off',
};

Step 2 - Remove legacy overrides

This block can also be removed

  // Legacy Code - remove from `files` when adopting desired rules in new code progressively
    {
      files: [
        'client/src/entrypoints/admin/core.js',
        'client/src/entrypoints/admin/page-editor.js',
        'client/src/entrypoints/admin/telepath/widgets.js',
        'client/src/entrypoints/contrib/typed_table_block/typed_table_block.js',
        'client/src/utils/version.js',
      ],
      rules: legacyCode,
    },

Step 3 - Add back two ignore rules for components

Add back no-continue and no-restricted-syntax to the components ignoring - I did a bit of digging and the changes needed here to satisfy these rules would take a long time and will not give us a big benefit.

    // Rules that we are ignoring currently due to legacy code in React components only
    {
      files: ['client/src/components/**'],
      rules: {
        'no-continue': 'off',
        'no-restricted-syntax': 'off',

Step 4 - run fix & format

Now run npm run lint:js -- --fix

This will run the eslint fixer to fix up a few automatic things (no-else-return items)

Then run npm run format to clean up any odd formatting from Eslint

Step 5 - Ignore a few inline items

These two files will flag a linting warning default-param-last - but to refactor this code to meet the eslint rules will require a rethink of a key part of the redux structure in this code and is not worth it - just add an inline ignore.

• wagtail/client/src/components/PageExplorer/reducers/nodes.ts
• client/src/components/PageExplorer/reducers/explorer.ts

Try to do it inline like this for them - it reads a bit better

/**
 * Contains all of the page nodes in one object.
 */
export default function nodes(
  state = defaultState /* eslint-disable-line default-param-last */,
  action: Action,
) {

Step 6 - The actual clean up bit 😃

Once you have done this, running npm run lint should expose only a few small linting items to fix up.

/client/src/entrypoints/admin/core.js
  155:9  error  iterators/generators require regenerator-runtime, which is too heavyweight for this guide to allow them. Separately, loops should be avoided in favor of array iterations  no-restricted-syntax
  167:9  error  iterators/generators require regenerator-runtime, which is too heavyweight for this guide to allow them. Separately, loops should be avoided in favor of array iterations  no-restricted-syntax

/client/src/entrypoints/admin/page-editor.js
  136:5  error  iterators/generators require regenerator-runtime, which is too heavyweight for this guide to allow them. Separately, loops should be avoided in favor of array iterations  no-restricted-syntax

/client/src/entrypoints/admin/telepath/widgets.js
  298:5  error  iterators/generators require regenerator-runtime, which is too heavyweight for this guide to allow them. Separately, loops should be avoided in favor of array iterations  no-restricted-syntax

/client/src/entrypoints/contrib/typed_table_block/typed_table_block.js
  460:7  error  iterators/generators require regenerator-runtime, which is too heavyweight for this guide to allow them. Separately, loops should be avoided in favor of array iterations  no-restricted-syntax
  461:9  error  iterators/generators require regenerator-runtime, which is too heavyweight for this guide to allow them. Separately, loops should be avoided in favor of array iterations  no-restricted-syntax
  513:5  error  iterators/generators require regenerator-runtime, which is too heavyweight for this guide to allow them. Separately, loops should be avoided in favor of array iterations  no-restricted-syntax
  514:7  error  iterators/generators require regenerator-runtime, which is too heavyweight for this guide to allow them. Separately, loops should be avoided in favor of array iterations  no-restricted-syntax

✖ 8 problems (8 errors, 0 warnings)

All of these problems are with the usage of for in... loops, give a go at changing them to array methods (such as myArray.forEach or myArray.map or myArray.some / find).

For example, here is how we could solve the issue in page-editor.js

original

  const updateWarnings = () => {
    for (const warning of warnings) {
      const visible = typeVisibility[warning.dataset.unsavedType];
      warning.hidden = !visible;
    }
  };

proposed

  const updateWarnings = () => {
    warnings.each((warning) => {
      const visible = typeVisibility[warning.dataset.unsavedType];
      warning.hidden = !visible; /* eslint-disable-line no-param-reassign */
    });
  };

I realise this is a bit odd as we are still disabling a rule but there may be a better way with jquery to set a hidden attribute.

Recap

It’s 100% ok if we have to ignore a few discrete files for a specific rule here and there. The reason we want to finish this is so that we do not have to much ‘blanket’ ignoring of entire files or areas of code if it can be avoided.

So even if you end up fixing 1 or 2 of the files from step 6 above - that’s all good.