Use Mega-Linter locally

[withinfocus]

🎟️ Tracking

Internal change.

🚧 Type of change

• 🤖 Build/deploy pipeline (DevOps)

📔 Objective

Adds the Mega-Linter via its runner package and executes it for staged file linting. Relates to #2 and its Actions-based approach. Will lint and apply fixes.

⏰ Reminders before review

• Contributor guidelines followed
• All formatters and local linters executed and passed
• Written new unit and / or integration tests where applicable
• Used internationalization (i18n) for all UI strings
• CI builds passed
• Communicated to DevOps any deployment requirements
• Updated any necessary documentation or informed the documentation team

🦮 Reviewer guidelines

• 👍 (:+1:) or similar for great changes
• 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
• ❓ (:question:) for questions
• 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion
• 🎨 (:art:) for suggestions / improvements
• ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
• 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
• ⛏ (:pick:) for minor or nitpick changes

[bitwarden-bot]

Checkmarx One – Scan Summary & Details – 759b9ef6-0771-4539-9b16-b612921054bc

No New Or Fixed Issues Found

[Hinton]

Summarization of my previous concerns and desired behavior on this topic.

CI:

• Run formaters and linters on all files. Otherwise files might be missed which I've encountered with previous tools.
• Specific tools should always block merge. (Prettier, eslint etc) Other tools/rules should perhaps not block merge. This needs to be configurable.
• We need control over when megalinter is upgraded (ideally on a individual tool level), to ensure breaking changes are applied on all files. (Prettier & eslint have changed rules between minor versions).

Local:

• Run on staged files primarily.
• Allow option to run on all files, useful during merge conflicts.
• Reasonable fast.

Downsides over husky/alternatives.

• Non standard tool. Higher threshold for external contributors.
• Presumably slower.
• Requires initial configuration over slowly enrolling more linters.

I still have a hard time seeing the value of throwing a ton of linters on a codebase over focusing on enabling more eslint rules for pain points we've encountered. If this becomes the standard the owner of this effort will need to spend time ensuring it runs smoothly in all repositories prior to disabling any existing workflows.

[withinfocus]

Open to suggestions on cleaner Bash scripting for this flow.

[withinfocus]

oxsecurity/megalinter#2921

[withinfocus]

Current thoughts:

• Open to discussion on how active the local version is vs. what we do via Actions on GitHub, if anything. Can we live with blocking the whole run? Not sure how configurable this can really be vs. configuring the linters and formatters themselves.
• Use of Mega-Linter isn't going to give flexibility to linter upgrades and it's pretty aggressive. I think it's a cause for concern when a linter breaks an interpretation, but I think in practice we have to roll with what's provided and not necessarily block e.g. 06e00c5.
• This is the template version and we'd expect .mega-linter.yml to be a major customization point in repos.
• I received decent surprise that NPM tools would be everywhere and this is move to pure hooks is partly a reaction to that. I am not sure what we're missing at this point in the PR though vs. Husky and lint-staged.
• As a company moving more and more to SOA, toolchains will adapt and we'll be exposed to a multitude of languages and approaches. A default catch-all tool is a powerful sieve and with default / expected configuration for all those tools also landing here will give a solid starting point for work (and new projects) to not go awry.
• With this as the "base", new repos will adopt it automatically and grow with its robust offering. Existing repos should also adopt it and see what fits for configuration, but still wanting "more linters" because it will give more feedback and more improvements. Making sure it works everywhere before anywhere is not the plan because it will be a fit via contextual configuration.
• The clients repository has gone farther with linting than practically everywhere else and some of its paradigms may skew assessment here, but we want even all our current repos to benefit, especially since we have a lot of .NET ones that don't really receive much if any feedback. Rust and the other SDK implementations (Java, Swift, Python, and so on) have much to gain.

[withinfocus]

The above PR from Mega-Linter is merged and a beta "formatters-only" flavor now exists and I put it in use here. We'll want to see it leave beta before we merge ourselves.