Super-linter: Clearify what is the intended workflow for using Super Linter locally

[essenmitsosse]

Coming from ESLint my workflow is kind of like that (super simplified), if you clone a repo, that is setup with ESLint, here is basically what you have to do:

• npm install
• npm run lint (or whatever it is called)

Something as simple as this doesn`t seem to be possible with Super Linter for obvious reasons, because you would have to setup the docker container, and then maybe you could add the docker script as a NPM script. But it seems like, that is not how Super Linter is even intended to use.

So the question is: How is Super Linter meant to integrate with day-to-day local development.

I am still a bit confused. For me a Linter mainly is used locally while developing - auto fixing being a must have. Having a linter check run as part of a CI in a VM is an added bonus. Super Linter seems to completely focused on CI.

My best guess would be: Keep on using ESLint through NPM locally and just use Super Linter action for CI.

Either way, would be great if that could be clarified in the Readme.

[kkweon]

Thank you @essenmitsosse for the pointer.
~+1 Please add a documentation on how to run it locally. There could be a discrepancy in versions or configs. Running a local linter could cause a trouble.~

[essenmitsosse]

There already is one, but it seems to be more for debugging super linter, then to actually use it everyday in a project.

[zkoppert]

Currently my workflow is to commit and push often to a pull request and let the ci do its thing while I keep working. I would be open to suggestions on how we might accommodate more local use if it could integrate nicely. Have to spend some time brainstorming that.

[essenmitsosse]

I think the major difference is how immediately you want feedback. For me a linter is not just supposed to make sure no low-quality code is submitted, its purpose is also to help me get readable code right as I write it, as well as give instant feedback for errors like missing variables. I have a shortcut in the IDE, that formats the whole file I am working on. This way I can just hack down code and then let the linter do its magic regarding formatting. Have to submit the code to CI every time would be some orders of magnitude slower than the current workflow. Also I'd be pushing a huge amount of unnecessary commits to origin.

Or to put it in other words: I let a linter clean up code way more often, then I need feedback from the whole CI pipeline, even when doing tiny, granular commits.

It should be noted, this is not just about auto fixing, but also about integration with the IDE.

I think the question is: Does Super Linter want to be a replacement for everything linter related, or does it just want to streamline the CI process?

[GaboFDC]

I think you are seeing super-linter as just a linter for any language, which this is not. Super-linter is a wrapper that under the hood uses the most popular linter for each language/file, intended to be used as a GitHub action, so you can have only one action to lint everything, instead to having to setup each of the used linters actions and maintain all of them.

[essenmitsosse]

Exactly, thats what my question for clarification was about. Would be great to hear the official stance on this.

In that case I would definitely try to improve the readme, because from the name alone it sounds like its supposed to be an all-in-one solution, that replaces all individual linters.

Also if it's only supposed to be wrapper for CI, so I don't have to setup each and every linter, but then I have to set it up anyway to use locally I don't really see the benefit of an additional dependency. Especially since the rules for Super Linter are in special folder and not in their default place for the individual linters being used. So If I want a local setup for a linter, I would not only have to set it up manually, but also make sure to keep the rules in sync.

[IAmHughes]

@essenmitsosse thanks so much for this issue and questions/points you bring up.

I'll let @admiralAwkbar confirm, but I think the current posture is as follows:

• super-linter is a GitHub Action to allow a single action to cover all your linting needs in your CI pipeline
  
  
  
  • GitHub Actions are not something integrated into any IDEs in terms of running them locally, and therefore I think local running of super-linter to replace your IDE/editor's linting is a little out of scope of the original intention
  
  

That said, I would LOVE to get this setup as an integrated plugin to popular editors/IDEs, but that would be a long ways off.

Potential workarounds for now would be as you stated, have the docker image built locally and add the docker command to your local build (npm, maven, gradle, whatever). Not ideal, but I think that would be close to providing the functionality you're looking for.

[admiralAwkbar]

@essenmitsosse great points. This was intended to follow the GitHub flow of opening a pull request early and pushing often.
This then allows for greater collaboration and helps make sure every change and fix is documented. We added some new variables to allow you to keep your rules files where they are, so you don't have to follow the one folder to rule them all approach...

But getting this to work more native and closer to the development chain, would be a great addition. Not everyone builds code the same way, and we're trying to make this open for all approaches.

[essenmitsosse]

@IAmHughes @admiralAwkbar Thanks for the clearification. This helps a lot. I am not sure how many people run into the same confusion, but from my perspective it would be great to put this in the readme, that this linter is just meant for the CI process, not (yet) for local development. With hindsight that could have been clear from the current Readme, but if you expect a linter for local development it could take a moment to figure this out.

[zkoppert]

Created a PR to clarify documentation. Check it out here and let me know what you think.