Live data from Hacker News

GitHub Super Linter: one linter to rule them all

github.blog

131–140 of 360 posts

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

#131
post #33

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.

looks like it's changing now: https://github.com/github/super-linter/pull/137

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

#132

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.

IF you're the only one, maybe the talking points are correct... Care to explain why you dislike it?

See here https://news.ycombinator.com/item?id=23566213

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

#133

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…

Yeah -- we use Python Black and it's a blessing. The entire purpose was to replace linting so that we could have something extremely opinionated so that people could stop arguing.

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

#134

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…

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…

Why don’t we just check ASTs in to git instead of text files ?

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

#135
post #55
post #47

Earlier 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.

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

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

#136

Earlier 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.

This is something that keeps coming back to me either as a feature or as a product of some kind - a tool that can stop this from getting in our way.

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

#137

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.

I'll stand with you. I understand the arguments for linting, but the only positive from my perspective is that it scratches enough itches of the Type As out there that they'll climb off my back and get back to being useful...well get back to "organizing" whatever else it is they think is too unruly.

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

#138
post #114

Earlier 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…

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?)

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

#140
post #86

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.

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

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.
Post reply on HN