Earlier quoted context omitted.
Hi, there is a local run option with instructions here: https://github.com/github/super-linter/blob/master/docs/run-...
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.
GitHub Super Linter: one linter to rule them all
131–140 of 360 posts
Re: GitHub Super Linter: one linter to rule them all
#132Am 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.
IF you're the only one, maybe the talking points are correct... Care to explain why you dislike it?
Re: GitHub Super Linter: one linter to rule them all
#133Great! 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…
This seems like a cool tool, but I don't know if I would use it at this point. I would _pay_ for having autoformatters from Github -- it was a pain to set it up and would love to just enable on new projects.
Re: GitHub Super Linter: one linter to rule them all
#134Great! 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…
Code autoformatting is amazing and I never want to go back; even though I strenuously disagree with the particular formatting my team/company has chosen for python, I'm so relieved to never ever have a style discussion in PRs that I don't care about double quotes vs single quotes anymore. BUT I'm tired of seeing diff chunks on github where 95% of the chunk is because black/gofmt decided to change the formatting / ind…
Re: GitHub Super Linter: one linter to rule them all
#135Earlier quoted context omitted.
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
#136Earlier quoted context omitted.
How so? If the canonical format is applied every time you save, you'll always be doing a diff with files using the same format. Of course, it does mean the code in the diffs may not be in your preferred format.
If you want to diff against anything in the past you get a bunch of formatting noise that occludes real changes.
The simplest and safest would be to apply the formatter to both the old and the new copy before diffing it. It ceases to be the actual difference at that point, but there are definitely two distinct use cases for diffs - one for humans to read and one for the machine to apply.
The other case that would be amazing but even more of a stretch would be to rewrite the entire history. It seems like there is a spot for "different views of history" and you could do a no-difference merge to join the to histories as of now so that the actual history did not get lost. As I write this, it starts to sound like just a caching system for the idea above.
This needs a highly reliable formatter of course... I have on occasion had code broken when formatting.
Re: GitHub Super Linter: one linter to rule them all
#137Am 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.
Re: GitHub Super Linter: one linter to rule them all
#138Earlier quoted context omitted.
What do you dislike about bugs being highlighted as you type, rather than first having to run your code?
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. M…
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?)
Re: GitHub Super Linter: one linter to rule them all
#139Re: GitHub Super Linter: one linter to rule them all
#140Is 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.
It’s MIT License. You’re free to fork.