Increase ESLint requirements for new files

[Pezmc]

Do not merge after review: I'll merge main into this branch first to ensure it's up to date.

Description

This PR increases our ESLint rule requirements in two ways:

• Moving from plugin:vue/vue3-essential to plugin:vue/vue3-recommended
• Enabling plugin:import/recommended which validates import paths and keeps the order of imports consistent

Importantly these new rules only apply to new files, that is to say, any file that doesn't meet the new higher standard, now has an override set in the ESLint.

This means that new files are held to a higher standard, they're more consistent and more bugs and patterns likely to lead to errors are caught, while still allowing the old failing files to exist.

The significant majority of the new rules all support eslint --fix, which should be enabled in your editor as per the handbook or run manually with npm run lint:fix.

Impact to team: Theoretically zero if auto-fix is enabled in your editor
Impact to codebase: Stricter standards catch bugs earlier and improve consistency making work faster

Related Issue(s)

None

Checklist

• I have read the contribution guidelines
• [-] Suitable unit/system level tests have been added and they pass
• [-] Documentation has been updated
  • Upgrade instructions
  • Configuration details
  • Concepts
• [-] Changes flowforge.yml?
  • Issue/PR raised on flowforge/helm to update ConfigMap Template
  • Issue/PR raised on flowforge/CloudProject to update values for Staging/Production

Labels

• [-] Backport needed? -> add the backport label
• [-] Includes a DB migration? -> add the area:migration label

[Pezmc]

734d71a has failures not seen locally, downgrading to a draft.

[Pezmc]

@Steve-Mcl @knolleary @joepavitt This is ready for review!

[Steve-Mcl]

@Pezmc - loaded onto windows machine & tried creating new files etc - as expected, tighter linting rules were shown for new files (e.g. copying many of the existing VUE files showed numerous new warnings and errors) 👍

1 Question I have is:
Most of the linting markers are only "warnings". Is this deliberate or should we be stricter?
E.g. enforcing order of directives makes for a familiar VUE file layout.

[Pezmc]

Thanks @Steve-Mcl, I'll be rebasing this branch on top of main just before it merges to ensure we don't have failures for files currently on other branches.

I've left Vue.js style issues as warnings only rather than errors, that is to say, they don't cause problems, but ideally we'd fix them up. The majority of the warnings can be auto-fixed, but not all, so it felt best to leave it as a warning, rather than a hard requirement.

[knolleary]

My concern here is we now have over 1000 lines of exceptions hardcoded in the lint file. Is the intent to slowly chip away at those in the background when those files get touched for other work that is in plan?
The file says that list is autogenerated - how was that generated? Would be helpful to have that documented in the PR for future reference.

[Steve-Mcl]

I had a similar question to @knolleary on what our intent was following this.

Perhaps we raise an issue (or several) to do "sections" of the code base to reduce this list of files?

[Pezmc]

The very long term objective would be to clear the list of exceptions, but given that it doesn't bring that much value just yet, and is likely to make a mess of git history if run using --fix, I'd suggest it was very low priority here.

The key objective here is to hold new files to higher standards, rather than being forced to use lower standards because of the older files in the codebase.

@knolleary The overrides were generated using npx eslint -c .eslintrc -f overrides --ext .js,.vue "**" referenced in 9209734, but there shouldn't be a need to update the list once it's set.

[Pezmc]

@knolleary @Steve-Mcl Would like to get this merged, did you have any follow up questions?

/cc: @joepavitt @hardillb

[Steve-Mcl]

@Pezmc I do fully agree we should not simply --fix everything in one go however, we should (IMHO) actively progress the removal of exceptions to get the whole of the code base up to a higher standard. Some options/approaches might be to:

• have a rule whereby if you work on a file that is present in the list, you remove it from the list and fix up any lint issues as part of that work.
  • Perhaps we consider adding a checkbox or reminder to the git template?
• have a bunch of open issues Have an issue with sub tasks that target sections of the code base
  • To ensure this does not get left behind.

Otherwise, as stated before, in my testing, this was working as expected. So long this doesnt just become technical debt & we have plans to whittle this down, I personally approve.

[hardillb]

I'll say yes to this, but I think we should have a tax to pull the exceptions down.

e.g. an issue per release to remove one of the exception blocks

[Pezmc]

In the interests of maintaining bias for action, I'm merging this PR, we can continue to finesse the best way to keep track of the list (see @Steve-Mcl's comment above) on this thread.