Other Tools section in README + Mega-Linter

[nvuillam]

• Add Other tools section in README + Mega-Linter
• Activate Mega-Linter in repository as GitHub Action
  • Add .cspell.json for whitelisted unknown words
  • Add .eslintrc.yml for Eslint javascript linter
  • Fixes for detected issues
  • Add Mega-Linter Badge

Your great links checker page in Mega-Linter is https://nvuillam.github.io/mega-linter/descriptors/markdown_markdown_link_check/

If you have a logo that I could add, please notify me :)

[nvuillam]

I think I answered or fixed all your remarks, please tell me if anything is not clear :)

[cadeef]

I'm a proponent of linting and it's something I figured worth bringing up for MLC eventually, but honestly this PR makes me a bit uncomfortable. Without wading into the intention of the PR, which I believe slightly suspect, why the choice of Mega-Linter instead of something more surgical and mature like pre-commit?

I'm sure that Mega-Linter is a fine project (I've browsed briefly and it looks neat), but is it the right tool for MLC? There are numerous projects in the space that should probably be evaluated prior to implementation.

@nvuillam, as the project author, what are the compelling features of Mega-Linter? How does it differentiate from other linter frameworks in the space? I've read Mega-Linter vs Super-Linter, but have I missed comparison with other tools that provide full workflow integration? Honestly, I find lack of first-class local support and git integration a deal breaker.

[nvuillam]

@cadeef I fully understand your concerns, and probably would share them in your position :)

Mega-Linter is indeed quite new compared to well known tools like Sonar, Codacy, etc... but :

• it is based on a hard-fork of GitHub super-linter, where I was an active contributor, which is used on thousands of repos, so ... it is not so new, and is even more stable thanks to hardcore CD/CI checks implemented on it !
• No integration/registration anywhere is necessary to use it: repos code remains where it is and is not send to external servers, who later would propose some paying options etc...

To help take-off, I propose to add a link in the README of the great linters included. If I see that there is no code quality tool defined, I propose to install Mega-Linter, and solve the fixes: I see that as a win-win "Clean code base and ensure clean code in the future PRS, vs give some visibility to my tool" (that I hope will soon have more contributors)

About running locally, I agree that there are some evolutions that could be performed, but the main goal is really to prevent all PRs to contain dirty stuff, while improving the developers knownledge about best practices

But if you refuse the PR, no problem, I can just remove mega-linter.yml in the workflow and just publish the README and fixes I perform, please let me know :)

[NicolasMassart]

But if you refuse the PR, no problem, I can just remove mega-linter.yml in the workflow and just publish the README and fixes I perform, please let me know :)

Maybe we can split in two PRs so we don't mix MLC improvement and mega-linter advertising?

I share @cadeef feeling and that's the first thing that came to my mind. But even assuming good intent and the quality of your tool, one question remains: I this scaled for a project like markdown-link-check?

We just started to increase contribution to this project and I'm very happy to notice a real interest in this project and new contributions. Including yours.

But we have a lot to do already and you can look at our project board for the way we prioritise things https://github.com/tcort/markdown-link-check/projects/1 if you want to pick some work to make the project go faster.

I would be happy to review the value of your proposal if you could create an issue first that would describe what it provides to the project, what issue it fixes, how it's fulfilling MLC needs and elaborate on your motivations.

Directly pushing a PR like this one (it's a big one) is not a good practice if we want to improve this project management. The discussion we are into now is the proof that we need to discuss before it.

I admit that perhaps having a live discussion channel would help, I don't know if you would have asked us before if we had one, but the fact is that we don't have one on purpose and we expect contributors to discuss using issues.

Our CONTRIBUTING.md is clearly very small and maybe not fitting our new needs and I'm sorry if we let you think that you could just drop a PR without discussing it before. That's another thing we clearly have to improve.

Please let me know if you can perhaps create a new issue for the mega-linter part and transform this PR in a doc only one (only the README.md changes, even keeping the other tools section).

The best would be if you could propose other tools than mega-linter in this section, it would help use being aware of projects to take care of when we make changes that could potentially break compatibility with previous versions or simply to direct our choices for new features or priorities. I bet you may have studied your competitors a bit and that would be very valuable for us 😉

[cadeef]

I created a stub issue for discussion of linter frameworks.

[nvuillam]

@NicolasMassart > Message received, thanks :) I will split the PR and try to take part in the discussion :)

[tcort]

This has been dormant for a while and tagged as a draft, so I'm going to close it. Feel free to resubmit/reopen.