Live data from Hacker News

GitHub Super Linter: one linter to rule them all

github.blog

51–60 of 360 posts

Re: GitHub Super Linter: one linter to rule them all

#51
post #2

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

We added linter checks to our Travis CI config. It helps flag the PRs that don't pass the linter.

The problem I've seen is that the error message isn't obvious. It just says that the "build failed", which sounds more like a compilation error than a lint problem.

Re: GitHub Super Linter: one linter to rule them all

#52
post #44
post #34

Earlier quoted context omitted.

Outdated version could simply be counted as nonexistent, then a new version would be installed "as needed".

And then you'd need to figure out how to install that new version side-by-side with the existing one, or otherwise you will upgrade and break the existing setup of a lot of people. That is also not always trivial, especially if you have an existing setup like e.g. system python + pyenv managed python. Should the linters then be installed via the system package manager? How would you handle that across many different…

The "install as needed" linters of course should live in their own separate universe, not scattered everywhere.

Alternatively you ask people to install linters themselves, and refuse to run if they're outdated. Language X devs likely already have reasonably up-to-date language X linters installed, or know how to install them anyway.

A lot of effort: probably. Many different platforms: there are three platforms that carry any weight. See GitHub Actions runner environments.

Docker on the dev machines is easy for the project, but (1) performance is subpar on macOS and Windows due to virtualization; (2) it also gets outdated; (3) the image is easily gone if you like pruning, then you need to pull the image all over again. (Thankfully the image isn't huge, ~380MB at the moment.)

Re: GitHub Super Linter: one linter to rule them all

#53

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's been go-fmt that's converted me to this way of thinking. It's such a waste of time having a linter tell me after I've checked in code that I'm missing a space on line 123... please just add the space. Please let me and my colleagues never have to argue again about what is the right way to format something.

Re: GitHub Super Linter: one linter to rule them all

#54
post #25

Earlier quoted context omitted.

Docker is probably the least annoying solution, would you rather install linters for 40 different languages on your system?

I'd rather not run a linux VM for this, so yes. It should be possible to isolate it to /opt/github-linter/* on my BSD machines, or put into a nix package. (Also, I guess this is one more reason that docker is a big red flag for 'hastily hacked together unportable software that would be hell to ship.')

Look at the Dockerfile, it's all there. All 143 lines and 2 bash scripts. Are you about to introduce a new BSD ports package?

Re: GitHub Super Linter: one linter to rule them all

#55
post #47
post #41

Earlier quoted context omitted.

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

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

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

Re: GitHub Super Linter: one linter to rule them all

#56

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…

I can wholeheartedly recommend Black for Python, gofmt for Go, and terraform fmt for Terraform.

What are some other great formatters out there?

Re: GitHub Super Linter: one linter to rule them all

#57
> 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 ? The default rubocop is very angry about meaningless shit, curious where github falls on that spectrum.

Re: GitHub Super Linter: one linter to rule them all

#58
post #48

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…

GitHub Codespaces was announced at Satellite and it's basically what you say - a way for developers to skip the "setting up" step (often the most annoying step and single biggest blocker for OSS contributions) in a new repo. https://github.com/features/codespaces

Disclaimer, I helped make these :)

Re: GitHub Super Linter: one linter to rule them all

#59
post #33

Earlier quoted context omitted.

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.

What was Admiral Ackbar's famous quote?

It’s an exception?

Re: GitHub Super Linter: one linter to rule them all

#60
post #48

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…

Automated code review SaaS'es (using off-the-shelf linters, and more) have been around for what, a decade, or longer? So this is not "one step closer" to linting as a service.
Post reply on HN