GitHub Super Linter: one linter to rule them all • Hacker News Board

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

#211

Post by tomaszs » Thu, Jun 18, 2020, 9:56 PM UTC

zkoppert wrote: post #30

tomaszs wrote: post #5

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

Thanks for sharing that! I didn't know it existed.

Sounds great! I am sure you will enjoy it. If you have any feedback let me know. Cheers!

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

#212

Post by belval » Thu, Jun 18, 2020, 9:57 PM UTC

benatkin wrote: post #178

pensatoio wrote: post #171

Earlier quoted context omitted.

Installing Docker is so easy, and it’s significantly easier than installing individual tools when we’re talking about shared tooling and local development. But hey, you do you!

I'm about to uninstall Docker. I have a 128GB Macbook Air and it's taking up 17 gigs after some light use. I'll be using it from CI instead. I like it but it isn't a no-hassle option. It depends on the project whether it's easier. I prefer to avoid it if I can.

Not to be that guy, but I feel the 128GB drive is more to blame than Docker at this point. 17GB just isn't that outlandish these days.

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

#213

Post by ScoutOrgo » Thu, Jun 18, 2020, 10:13 PM UTC

philwelch wrote: post #56

tlrobinson wrote: post #37

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?

I really want one for sql, but haven't found any good ones available.

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

#214

Post by ryanblakeley » Thu, Jun 18, 2020, 10:15 PM UTC

VectorLock wrote: post #204

kristopolous wrote: post #104

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'm strongly against over-bearing autoformatters. In my experience a little hand crafting tweaks to formatting go a long way to increasing understandability. It feels like a lot of people are having issues with bikeshedding and they're using enforced autoformatters to impose their will and stifle debate they may not like. Not arguing about style is nice, but having to resort to this brutalist architecture style of co…

i completely agree with you. i think the people who advocate for auto-formatters must not be very skilled at using their text-editors and/or don't put enough attention on readability/understandability. i'm happy with linters and command line tools to auto-format when you explicitly call for it, like `eslint --fix`; i'm just not on board with the formatter running on git hooks or in whatever automated workflow.

almost every rule has an exception where understandability could be improved by violating the rule, ex. line length. code format is huge for understandability/readability, which makes it worth paying attention to while you're writing.

in my experience the loudest advocates for code formatters are the ones who write really complicated code; which makes sense that they just hammer on code until it works without being able to reduce and simplify their logic and naming.

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

#215

Post by deadbunny » Thu, Jun 18, 2020, 10:15 PM UTC

philsnow wrote: post #110

tlrobinson wrote: post #37

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…

The frustration is real in a PR situation when you have your editor set to run a formatter on save (same thing with stripping whitespace) but if you have enough control of the project and want to switch to using a formatter then git can help you there.

You can do a format run over the whole codebase then ignore the commit in blame.

https://www.moxio.com/blog/43/ignoring-bulk-change-commits-w...

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

#216

Post by sailingparrot » Thu, Jun 18, 2020, 10:23 PM UTC

softwaredoug wrote: post #79

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.

Serious question: what should a company like MS do in that position ? I think this is a nice feature and it's useful, it's also open source and MIT licenced, so in other word, it's an open as it can get. Is there anyway for MS to not making you uncomfortable apart from just not adding any new feature ?

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

#217

Post by reledi » Thu, Jun 18, 2020, 10:31 PM UTC

celticninja wrote: post #85

FredrikMeyer wrote: post #75

Earlier quoted context omitted.

Many linters have built-in auto-fix features like what you describe. (eslint, for example)

rubocop -a For the win.

Not the same experience as some of the best formatters out there. RoboCop is too configurable and too slow.

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

#218

Post by zkoppert » Thu, Jun 18, 2020, 10:33 PM UTC

sdesol wrote: post #185

avtar wrote: 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.

GitHub's Super Linter has an unusual history. See below for example: https://imgur.com/KZ008vu https://imgur.com/yJSHIWS admiralawkbar accounts for 80% of the commits in the repository and over 98% of the code churn. I'm guessing this was a side project of his (Lucas Gravley aka admiralawkbar) and the docker image was just something that was overlooked when it became an officially advertised GitHub repo.

Yup, thats exactly what happened.

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

#219

Post by erichurkman » Thu, Jun 18, 2020, 10:33 PM UTC

dtech wrote: post #154

kevin_thibedeau wrote: post #94

Earlier quoted context omitted.

If you want to diff against anything in the past you get a bunch of formatting noise that occludes real changes.

Usually when introducing such a tool you do 1 commit that reformat the whole codebase to the new style and then automatically enforce it.

And in those large reformat commits, add a file like `.git-ignore-revs-file` that is checked in, so you can configure git to ignore that revision and pretend it never existed:

    [blame]
      ignoreRevsFile = ".git-ignore-revs-file"
      markIgnoredLines
      markUnblamableLines

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

#220

Post by nilkn » Thu, Jun 18, 2020, 10:36 PM UTC

BurningFrog wrote: post #174

nilkn wrote: post #149

Earlier quoted context omitted.

But what do you get in that regard by not using black? Maybe in 1% of cases you’ll find a better way of formatting that everyone will also agree is better. That doesn’t seem worth very much at all to me, especially when by not using it you have to do a lot of manual work across the entire team now to get the 99% that is free with black.

Black is not free. At least not for me. I have to put in a fair amount of work to get Black to produce decent code. Things like changing names to affect line breaks, inlining or outlining expressions etc. Small things can turn 1 line into 8, and vice versa.

I’d be willing to bet that in many cases where you feel you need to fight against it, many other folks wouldn’t actually agree that your changes are objectively an improvement.

Now, to be clear, I’m sure it’s possible to find some examples where most programmers would come together and agree that black made the wrong decision. But my experience using it across entire teams is that this is surprisingly rare.