Add Mega-Linter

[nvuillam]

• Activate Mega-Linter as a Github action workflow
• Add info in README

[codecov-io]

Codecov Report

Merging #16 (b645765) into main (566da4b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #16   +/-   ##
=======================================
  Coverage   73.61%   73.61%           
=======================================
  Files           2        2           
  Lines          72       72           
=======================================
  Hits           53       53           
  Misses         19       19           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 566da4b...b645765. Read the comment docs.

[chris48s]

I have evaluated MegaLinter on its merits, but I don't think it is the solution I want to use for linting on this project.
In general, I think it is mostly beneficial to manage any linters, plugins and what versions of those are being used in the repo itself rather than outsourcing it to another project (certainly for those dependencies that exist within the same language ecosystem). For example, if I specify the version of eslint I am runing in my package.json then I know the version I run locally is the same as the one that runs in CI. If I farm it out to an external service there is potential for the versions to run with one version locally and then get a different one in CI. If I need to account for a major version change, that all happens in the PR that bumps the dependency, etc.
Obviously it is a matter of taste and some people will find this useful. I wish you luck promoting it, but I don't think it is the approach I want to follow.

[nvuillam]

I understand your point... about eslint
But if I deactivate Javascript linting, all the other ones would remain (markdown, dead links, spelling mistakes, own V8r ...)
don't you think it could be of interest ?

[chris48s]

At the moment, I don't want to take on all that overhead. If I do want to adopt some/all of that tooling, I'd rather manage the dependencies in my own manifest as far as possible for the same reasons I prefer to do that with eslint. As I say, its a matter of taste.
If I change my mind, I'm aware your project exists :)

[nvuillam]

Your repo = your choice, no problem ;)

[nvuillam]

@chris48s would you agree if I let just the README part ?

Just to have a hearth here :p https://nvuillam.github.io/mega-linter/all_linters/

And if you can star the repo, and you're an angel :)

[chris48s]

I have noted that you are on a mission to try and promote MegaLinter via other people's READMEs with PRs like these:

• Add Mega-Linter in list of integrations adrienverge/yamllint#349
• docs: Add CI usage & Mega-Linter in README cjoudrey/graphql-schema-linter#272
• Add "With other tools" section + Mega-Linter dzhu/rstfmt#1
• Add installation instructions for CI forcedotcom/sfdx-scanner#307
• docs: Add Continuous integration section + Mega-Linter lunarmodules/luacheck#13
• Add link to Mega-Linter (including rstcheck) rstcheck/rstcheck#73
• Add CI & Mega-Linter link in README pinterest/ktlint#1028
• etc

While I wish you luck with your project and some project authors may accept your PRs, I don't plan to recommend any projects I don't use myself here.

[nvuillam]

A guy has to try ;)
And for the repos still maintained usually it works ;)

But no problem, my efforts are starting to pay, it's slowly taking off, usually with people deceived by super-linter ^^

Have a nice evening 🥳