
GitHub Super Linter: one linter to rule them all - Amorymeltzer
https://github.blog/2020-06-18-introducing-github-super-linter-one-linter-to-rule-them-all/
======
tlrobinson
Great! Now do it for code formatters!

After using Prettier for a few years I'm firmly in the camp of
mandatory/enforced code formatters. As long as it's a half decent formatter
like Prettier I believe my personal opinions on the specific formatting
choices are much less important than essentially never having to think about
formatting again, in particular having to ask people to fix formatting in code
reviews (or fix it myself).

I also love just banging out code, saving, and having my editor clean up the
formatting for me.

~~~
honkycat
One of the hills I am willing to die on is auto-formatting. Code formatting is
easily automated to an acceptable level, and people's personal preferences are
subjective.

I like to solve interesting problems, and concentrate on crafting high quality
software. Manual code formatting contributes to neither of these disciplines.
Code formatting is BORING robot work, not human work. Total pointless
drudgery. Toiling away because you like your bracket with a different spacing
is IDIOTIC. Run the formatter and move on.

~~~
VectorLock
Normally I agree with treating code as a means to an end rather than an end to
itself but I take a certain enjoyment in crafting in some way aesthetically
pleasing code as well. I even find that if the code is "ugly" that there
frequently might be a more eloquent and objectively better way of doing
things. And a little time hand formatting I think is worth it if you're
maximizing understandability and readability.

Not arguing about style is nice, but having to resort to this brutalist
architecture style of code formatting doesn't seem great to me. "Its just
holding people, who CARES what the building looks like!"

~~~
forty
There are two kind of painting. You can paint a wall/a building, or you can
paint Mona Lisa.

This is the same for programming. Each dev have their own taste in term of
code style and code formatting preferences. I was an early employee in a
startup, and at some point I was able to tell who wrote a chunk of code just
from the code style, it was fun :) but as company grown, and team got bigger,
it got more "professional", now we have prettier which erases a big part of
our code personality. If you believe like me that coders are artists you might
find that a bit sad, but the truth is that most Enterprise software building
is wall painting, and art doesn't have its place there. That doesn't prevent
us from painting Mona Lisa at home though :)

~~~
javajosh
I like the point in general, but I will say there are times when idiosyncratic
formatting can really help understanding "this particular bit of code". Often
it has to do with aligning values so that they are easier to read; if a code
formatter was smart enough to at least understand the signal the programmer is
sending, and maintain (or even improve!) that kind of formatter, it would be
the best of all worlds.

One simple example is when you're parsing text and you have a long list of
simple one-line if statements. I personally think it's wasteful and harder to
read that block of code if you impose curly braces and new lines on that list
of conditionals. This kind of formatting convention has been around for at
least 40 years, and it makes the code more readable. I have yet to see an
auto-formatter that doesn't turn that kind of code section into an unreadable
mess.

~~~
dnautics
Or key value lists where the keys have slightly different lengths.

------
oefrha
A problem I can see with this super linter is that it seems be written
exclusively for GitHub Actions; there's no local install option. (I didn't
read the code, maybe you can use lib/linter.sh directly, but it's certainly
not directly supported.) So contributors have to rely on the CI feedback loop
to see if their changes are compliant (insert fencing comic here)... Or more
realistically, still use whatever linters they've been using so far, but now
you have to maintain linter configs in two places.

I get why it's probably not ideal as a local tool, and integration with Status
API is nice and all, but I personally prefer to see devs linting their code
before pushing for review.

Correction: it can run locally in Docker, as pointed out below:
[https://github.com/github/super-
linter/blob/master/docs/run-...](https://github.com/github/super-
linter/blob/master/docs/run-linter-locally.md)

~~~
zkoppert
Hi, there is a local run option with instructions here:
[https://github.com/github/super-
linter/blob/master/docs/run-...](https://github.com/github/super-
linter/blob/master/docs/run-linter-locally.md)

~~~
avtar
It's kind of odd that GitHub is asking people to pull an image from a Docker
account that most people won't recognize (admiralawkbar/super-linter), as
opposed to an official GitHub one.

~~~
markrages
What was Admiral Ackbar's famous quote?

~~~
whycombagator
“ask yourself if that answer doesn't make you look just a bit like a dewback's
cloaca”

------
LibertyBeta
So, this looks interesting. Rather than a real new linter, Github is proposing
a tool that runs against a number of common linting standards with a single
shared standard library.

Perhaps it would have been better pitched a Lint-runner for CI jobs rather
than a real linter.

~~~
zkoppert
Never thought of that! That does seem more accurate and descriptive.

------
softwaredoug
Is anyone else uncomfortable with Github/MS owning more and more of your tool
chain? Maybe my lock-in radar is faulty, but the more this happens, the more
scared I get.

~~~
lixtra
It’s MIT License. You’re free to fork.

~~~
softwaredoug
Yeah but only MS/GH have the resources to maintain a viable project here.
Little old you and me aren’t really going to reasonably fork something and
have the time to maintain it.

~~~
stu2b50
Hm, I wouldn't say so for the superlinter specifically. If you actually look
at the source, it doesn't seem particularly hard to maintain.

------
AJRF
There seems to be a universal law of software systems that if small, self-
contained subsystems exist - someone will glom them all together into an Uber-
system, and vice versa. It’s inescapable.

~~~
dbmikus
In business they call it bundling and unbundling:

> There are only two ways to make money in business: One is to bundle; the
> other is to unbundle. [1]

[1]:
[https://twitter.com/eriktorenberg/status/1214671238552940544](https://twitter.com/eriktorenberg/status/1214671238552940544)

------
jameslk
One step closer to Linting as a Service. That'll be next, along with
Compilation/Build Systems as a Service. Or more likely part of the whole IDE
moving to the cloud.

The pain being solved here is that setting up the right development
environment is hard, especially for those still learning to program. Many
would be much more productive if we skip this step.

Another prediction: Once the development environment moves to the cloud, it
will be tied directly to the deployment to a specific platform, such as Azure
if this is offered by GitHub. Then Amazon and Google will have to build their
own IDEs in the cloud to compete. We'll no longer be developing locally but in
the browser, and it will cost a lot more.

~~~
jtwaleson
I fully agree. The "I" in IDE (Integrated) has not aged well, just look at how
many parts of the software development cycle are outside of the IDE. It's time
to really integrate/bundle everything in a way that makes sense.

Things I want in my IDE:

\- monitoring/alerting (how many times is this method executed, how long does
it take, how many errors, etc)

\- discussions as in Google Docs on code fragments, rather than "comments"
that are part of the git history (comments are an orthogonal concern from
checked in code)

\- visual representation of my code base

\- ultra fast automated test that cover only what I recently changed

\- a documentation system that makes sense

~~~
jameslk
> The "I" in IDE (Integrated) has not aged well

This such a good observation. I will be using this quote in the future.

I've seen what integration of the development environment looks like inside a
big company (Facebook) and it's just amazing how seamless everything can be
when all your tools are built with an awareness of each other. I think we'll
see that soon outside these big companies.

------
mfontani
Yay for (some) Perl support!

The Perl validation seems to be restricted to "compile with warnings", despite
"perlcritic" being now almost 15 years old, predating both some other linters'
and even some other languages' very existence.

I'll try to see how feasible it'd be to add it as a ("the"?) Perl linter to be
used as using just the compilation step to infer everything's fine doesn't
really satisfy the role a linter is meant to have.

~~~
jwilk
Also note that "perl -c" can't be used securely against untrusted code:

    
    
      $ echo 'BEGIN{`cowsay pwned > /dev/tty`}' > test.pm
      $ perl -Mstrict -cw test.pm 
       _______
      < pwned >
       -------
              \   ^__^
               \  (oo)\_______
                  (__)\       )\/\
                      ||----w |
                      ||     ||
      test.pm syntax OK

~~~
obrajesse
Also, it looks like the perl linter only triggers against .pl files and not
.pm files

------
Vinnl
Seems like this is the equivalent to GitLab's Code Quality CI template [1]?
Which is supposedly built on Code Climate [2].

[1]
[https://docs.gitlab.com/ee/user/project/merge_requests/code_...](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html)

[2] [https://codeclimate.com/](https://codeclimate.com/)

~~~
mikewhy
We're in the process of stripping out Code Climate at work. Since it's
difficult to run locally, the whole "let CI run to see if your code lints"
isn't a great experience. And when first running prettier on our codebase, it
stated something like 8 days to "fix" it.

Just a poor experience all around.

GitHub's approach here seems much more sane.

~~~
mythshaker
They don't do the same thing

------
rdsubhas
What's very interesting in the list here: [https://github.com/github/super-
linter/#supported-linters](https://github.com/github/super-linter/#supported-
linters)

Java is the only major language without any sane default coding standard (no,
google-java-format is google-specific, outdated, not up-to-date with recent
versions and not maintained by community). It's a pity really.

~~~
ascorbic
I wonder why they went with Standard for JavaScript and TypeScript, instead of
Prettier which is far more popular now.

~~~
thefunnyman
As others have stated, prettier is a formatted not a linter. I do however
agree that Standard is a weird choice and in my experience is far from an
actual “standard”. IMO the Airbnb style is excellent and would have been a
better choice here. It’s also available as an ESlint plugin. Hopefully
something like this can be configured on the GH Action in the future, allowing
for a choice between available presets.

~~~
zkoppert
Sounds like there is some consensus around switching out Standard. Feel free
to open up an issue in the repo and we can discuss and move forward there if
you like.

------
globular-toast
> Setting up a new repository with all the right linters for the different
> types of code can be time consuming and tedious.

Is it? In my company I maintain a set of exemplars for all of our commonly
used repository types. When someone wants to make a new one they just copy and
paste stuff from one of the exemplars.

Over the years I've come to value "white box" code re-use over "black box" re-
use. In my experience many projects will outgrow their tools and need custom
tooling, so it makes sense to keep the black boxes tiny and copy over large
tooling in a white box fashion. For example, what if I want to change the
Python linter for Pylint to flake8? I'll need a separate fork of superlinter
or something. I'd prefer to just edit the tooling that is build in to my
project.

~~~
kstenerud
So basically you've done the same as super linter at your company. But now,
nobody else has to go through the pain of setting all of the exemplars up,
because you get nice defaults, everything included for free from super linter.

------
hultner
What I'm missing is a really good linter and auto-formatter for PostgreSQL or
just standard SQL. Haven't found something that seems well established and
well made.

~~~
OJFord
I was looking for one recently and was also surprised not to find anything
really. I thought there'd for sure be one already packaged for `pre-commit`.

------
jldugger
> The rule set for Ruby and Rails are pulled from the Ruby gem: rubocop-github
> and follow the same rules and versioning we use on GitHub.com.

Anyone know how this compares with
[https://relaxed.ruby.style](https://relaxed.ruby.style) ? The default rubocop
is very angry about meaningless shit, curious where github falls on that
spectrum.

------
ChrisMarshallNY
I think this is great.

I use SwiftLint for my code (Swift, not supported in SuperLinter, and I don't
expect it to be).

[https://littlegreenviper.com/miscellany/swiftwater/swiftlint...](https://littlegreenviper.com/miscellany/swiftwater/swiftlint/)

I am real big on code quality. LINT is not a silver bullet, but every little
bit helps. I also use things like -wall (or the equivalent, thereof, in
Swift), and heavy-duty code commenting.

[https://medium.com/chrismarshallny/leaving-a-
legacy-1c2ddb0c...](https://medium.com/chrismarshallny/leaving-a-
legacy-1c2ddb0c8014)

------
kristopolous
Am I the only one that dislikes linting?

Btw, you don't have to respond with the talking points I've heard all my life
on why it's supposedly great, I've obviously heard them and think they're
bogus.

I just find it strange that I'm the only one.

~~~
Vinnl
What do you dislike about bugs being highlighted as you type, rather than
first having to run your code?

~~~
kristopolous
This is just me btw, don't take offense:

Because some things are better expressed in different rules.

That's why some syntax is optional in the first place, that's the reason it
was made that way. The flexibility is a very intentional feature. It wasn't an
accident.

Maybe you want multiple spaces to vertically align code in a complex set of
logic. Maybe you want to express things on multiple lines to break them up.
Maybe you have deep nesting so you want to go from 4 spaces to 2. Maybe you
want no braces in a single line if statement except in certain cases. This
could go for pages. Poof! All gone. You can't do any of it anymore.

Not following optional syntax like having a space after a comma or a space
before a parenthesis is not a software bug. It's a waste of time. The compiler
doesn't care and I don't either.

Instead it becomes a literal Blocking Issue most of the time. So instead of
working on the actual blocking issues of the code base, you spend time doing
"you did this here because of some context I don't understand and I'm not
allowing it" You can't commit your code without conforming to it.

Also because linters are dumb. They "spot" things that are perfectly fine as
supposed bugs (because they don't actually know types or logic, they're just
dumb syntax checkers) and you have to work around them to satiate them with
the possibility of introducing new bugs to prevent some tripwire system from
false positives.

Compiler writers and language designers are the only people I've found who
agree with me.

It's fine for protecting against profound levels of incompetence but I don't
do that and you probably don't either.

~~~
Vinnl
So are you saying sometimes you _want_ to initialise a variable without ever
doing anything with it afterwards? That that's not the result of a typo down
in your code in the vast majority of cases?

I mean, I'll be the first to agree that blocking your development in the heat
of it over some stylistic issue like quote styles is counter-productive, but
if those rules are turned off and the rest help you catch actual bugs (and
it's hard to argue that it does not), then that's surely a plus?

(Also, why wouldn't linters know types?)

~~~
kristopolous
It hasn't been my experience. I have had to deal with linters probably about
15,000 or so hours of my work life (luckily that's only about a third). It's
been probably between 99.4% and 99.8% just acrobatic dog tricks to satisfy the
linter.

It's not like I'm some grumpy malcontent that hasn't given it a go.

If you want to use it go ahead, I just thought I'd be standing in a larger
crowd

~~~
Vinnl
Could it be that the problem with the linters you've experienced was that they
were just configured far too strictly about things that don't matter too much,
rather than linting itself being the problem?

I've got my linters set up pretty loosely, but the things that _are_ enabled
have definitely helped me detect bugs earlier and quicker, and I really don't
see how anyone could be against that.

~~~
kristopolous
well sure. There aren't bad tools just bad practitioners, sure. Certain tools
give more affordance to certain use cases and maybe that's the issue.

For instance something where I am the culprit would be in PHP. I like PHP. I
think it's a convenient and powerful language. Someone could take my linter
arguments and weaponize them against PHP because it's too easy to do terrible
things with it. Then I'd be the one on the other side of the argument all of a
sudden, standing in defence of this easy to use language with handy powerful
abstractions that can trash a system in a few keystrokes.

I think the difference is when we can come to an agreement that say, PHP is a
very powerful tool in competent hands and a very dangerous tool for the
foolish.

Going back to the topic at hand, I think the foolish side of linting is the
dominant application I see in the wild. I used to use a barrage of proto-
linting static analysis tools in my CVS scripts during the wild C days because
pointer logic and memory management was notoriously tricky and gcc 2.x was
notoriously forgiving. These tools could save days of debugging, really, yes,
days.

If we can do that for say python it'd be great. Something saying "Oh I see you
are doing a list[1:] in a tight loop, have you thought about
collections.dequeue? it may be a better option" \- those things are things I
do actually forget about and would find helpful.

It'd have to be voluntary though. Prod me a bit but then let me dig my own
grave if it's a mistake. That's what the power of computing is also about.

~~~
Vinnl
Yep, I can definitely agree there.

That said, I'd argue against strict stylistic rules, not against linters in
general. For example, the common Javascript linter (ESLint) has a setup wizard
that allows you to choose whether you just want to check for bugs, or also
enforce style conventions, and will enable a predefined set of rules depending
on your choice. The bug-spotter is the one that's preselected. This is a very
reasonable approach to me.

------
tbabej
Happy to see this development! There was an earlier attempt at universal
static linter by the coala project [1], however, in the recent years the
project was not keeping up with the underlying tools changing [2].

It's lovely somebody's picking up the torch here!

[1] [https://github.com/coala/coala](https://github.com/coala/coala)

[2]
[https://github.com/coala/coala/graphs/contributors](https://github.com/coala/coala/graphs/contributors)

------
amasad
The trend of putting developer tools behind a unified API is just awesome.
Especially great for tool makers like us at Repl.it. We're investing a lot in
this area too:

\- UPM: universal package manager
[https://github.com/replit/upm](https://github.com/replit/upm)

\- Prybar: universal REPL interface for interpreters
[https://github.com/replit/prybar](https://github.com/replit/prybar)

------
stevebmark
I don't understand why there's any innovation around linters. To set them up
as a PR hook, you literally just run a single linter command and check the
status code. Why use something like this, or the absolutely horrible tool
Codeclimate? Linting is a solved problem and easy to set up, and linting rules
should be a per-TEAM decision to empower teams to solve their own problems.

~~~
zkoppert
Totally understand. I think the problem we are trying to solve here is
integration with GitHub Actions as well being able to easily set up multiple
linters for code ASR’s with many languages. Hope that makes sense.

------
autarch
There are already quite a few projects that do this, and IMO do it better. I
did a write up of a number of them on my blog -
[https://blog.urth.org/2020/05/08/comparing-code-quality-
meta...](https://blog.urth.org/2020/05/08/comparing-code-quality-meta-tools/)

------
secondcoming
Visual Basic (6 at least) had none of these issues. It formatted your code as
soon as you pressed <enter>. Im don't recall ever having control over the
formatter, which was great because everyone's code ended up looking the same
and there was nothing they could do about it.

------
simonebrunozzi
They should have explained what a "linter" is at the beginning of the post.
[0]

[0]: [https://sourcelevel.io/blog/what-is-a-linter-and-why-your-
te...](https://sourcelevel.io/blog/what-is-a-linter-and-why-your-team-should-
use-it)

~~~
zkoppert
Considered that but thought the target audience might be familiar. I think
your suggestion would have made it more accessible though to those who have
not been around linters before.

------
silviogutierrez
This is great, but desperately needs a way to also fix these issues. And all
functionality should run locally as well.

I imagine the latter is possible thanks to it being a docker image.

So far I've been using this script I built for similar purposes:

[https://gist.github.com/silviogutierrez/3dca60a6b5b8fe214052...](https://gist.github.com/silviogutierrez/3dca60a6b5b8fe214052b45cfe7c9b63)

Runs locally, and only on changed files against master. Fixes all my python,
JS, yaml, terraform, etc. And you can run it against a single file too so I
integrated it with vim to replace all my linters.

I really hope the GitHub initiative projects takes off as a standard API (à la
language server) for linters and fixers. Seems every single IDE needs to
reinvent a plugin for applying a specific linter.

~~~
zkoppert
I think there is an opportunity to integrate/add your gist to the super
linter. Feel free to open an issue to get that started.

------
tomaszs
I like the way it improves the quality of deploys. Actually different approach
but same aim is hidden behind Assistant extension to Visual Studio Code. I
think both solutions are complementary to improve quality of team work. If you
want to check Assistant out version 0.9.0 was just released two days ago:
[https://marketplace.visualstudio.com/items?itemName=tomasz-s...](https://marketplace.visualstudio.com/items?itemName=tomasz-
smykowski.assistant)

~~~
acasajus
It would be nice if you said that it's your own extension...

~~~
tomaszs
My name is Tomasz Smykowski. Assistant is my design. And I am proud of it!

------
ausjke
Please someone design a cppfmt for c++ in the modern age.

If possible for C as well, to a less extent.

for clang-format, it can not even add blank lines between functions, and it
can not indent "public, private, protect" inside class sanely, which are two
very basic needs. The rest options are worse, however, but I hope something
better than clang-format.

------
b34r
Interesting, but ultimately the best linting tool is one that runs prior to
commit. Especially if it can auto-fix.

------
corndoge
No C/C++ support?

~~~
perryizgr8
You don't have linters for C/C++ as far as I know. I guess they could have
included code-formatters too, like clang-format.

~~~
KindOne
What about clang-tidy?

[http://clang.llvm.org/extra/clang-tidy/](http://clang.llvm.org/extra/clang-
tidy/)

cpplint?

[https://github.com/cpplint/cpplint](https://github.com/cpplint/cpplint)

------
BoDlulu
Lots of comments seem to not know about SonarQube[1], which is a meta linter
that has been existing for a while now.

[1] [https://www.sonarqube.org/](https://www.sonarqube.org/)

------
pabs3
This kind of reminds me of check-all-the-things:

[https://github.com/collab-qa/check-all-the-
things/](https://github.com/collab-qa/check-all-the-things/)

------
VectorLock
Reading through all these comments I see a lot of people saying "it stops the
debate about style!"

It seems like people are having more of an issue with bike shedding than
actual code formatting.

------
noja
Can we have something to beautify the code too? Like gofmt or shfmt?

~~~
oefrha
golangci-lint already supports gofmt. You just need to turn it on.

~~~
noja
shellcheck doesn't support formatting. I don't think some of the others
support formatting either.

~~~
oefrha
This is just a linter aggregator so someone has to write a formatter and
popularize it first.

~~~
noja
Yes. I was asking if they could consider adding a code formatter too.

------
aeyes
You got me motivated, ONE linter for everything.

Then I checked the code and see that this is a bash script which just runs the
language-specific linters packaged in a Docker container :(.

------
karanrajpal
Argh I just worked on exactly this idea, as a tool for my company! What do
people do when they see an idea they had/care about being implemented by
someone else?

~~~
derwiki
This is the nature of invention -- the current climate gives multiple people
the same good idea around the same time. You could abandon and join, convince
the other project to do the same, keep working on yours, stop working on yours
and use theirs... depends on your goals.

------
galaxyLogic
I'd like to find a formatter that aligns opening and closing braces and
parentheses vertically, if they span more than one line. Is there such a
formatter?

------
chadlavi
that's fine and all, but it sounds like I'd have to do a bit of manual work to
get the same exact set of linting rules locally, so that I can lint before
pushing.

CI linting/testing should be a final check, not a part of your iterative
workflow. Any linting or testing you do in CI should have already been done
locally by the dev.

------
iampims
I wish this would also prevent creating PRs that don’t pass the lint rules. It
reduces churn on PR reviewers.

~~~
beart
You could use something like
[https://github.com/typicode/husky](https://github.com/typicode/husky) to
prevent a push if the linter fails.

~~~
iampims
My (small) issue with git hooks, is that they need be installed everywhere for
them to be 100% enforced. Works fine for small teams, but doesn’t scale that
well beyond that.

~~~
azemetre
You make the hooks as part of the CI process. That's where something like
husky can come in. We do this on my team.

If you're trying to enforce something locally you can definitely enforce it on
CI automatically. Once people realized their PRs were failing due to linting
issues they started checking them locally as well.

------
acuozzo
Why does this post have so many commenters conflating lint & friends with code
formatting tools?

------
fergie
I feel like this is just softening us up for the inevitable vscode (online
edition)

------
avremel
Does the linter check all or only newly pushed code? Is this configurable at
all?

~~~
zkoppert
Checks all by default but you can set an env variable in the config to only
check new code.

------
envolt
Can someone recommend a Java alternative to ESLint for JS eco-system?

~~~
bilalhusain
Used `checkstyle` 4 years ago to improve the quality of code. Has neat XML
based rules and good IDE support. See if it fits your use-case.

------
wkoszek
GitHub got a lot of fire in their ... after acquisition. I was stunned how
fast GitLab overtook GitHub feature-wise, but looks like now they're at least
trying to compete.

------
angry_octet
And in the darkness combine them?

------
cool-RR
Obligatory XKCD comic: [https://xkcd.com/927/](https://xkcd.com/927/)

