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 :(.
GitHub Super Linter: one linter to rule them all
271–280 of 360 posts
Re: GitHub Super Linter: one linter to rule them all
#272Great! 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 really want to love Prettier, but I never want to spend the hours googling etc. on how to setup the frickin config files! Especially as someone who works on a wide variety of languages/file types, I really want to find a drop in formatter that works well enough in all situations.
I think you might be thinking of ESLint? Prettier has, like, 10 options, and they are all listed on this page [0], and you aren't required to even have a config file because the defaults make sense.
I personally find ESLint to be a nightmare of configurability and silly defaults.
Re: GitHub Super Linter: one linter to rule them all
#273Earlier quoted context omitted.
I will agree with you that shitty linters are shitty. > 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 an…
> If those checks are present I would disable them. The purpose of linters on a team - so I've been told - is so that no one has to argue about formatting anymore. So now we just get to argue about what rules we can enable/disable? Even though it's perfectly legal to disable linting for lines or files, most of the time when I do it, it's flagged by someone in review, and there's some discussion and I'm forced to rewr…
> The purpose of linters on a team - so I've been told - is so that no one has to argue about formatting anymore.
People who argue this are, I believe, missing the forest for the trees. A short on-the-spot version of something I've had in mind for a long time:
almost everyone has a slightly different style that they fall into and the individual styles arent necessarily difficult to understand
AT LEAST WHEN USED ON THEIR OWN, AND NOT MIXED WITH OTHER STYLES.
Your Brain Adapts To A Given One, When Reading That Style. It May Still Feel Like Stuttering, But Once Adapted It's Fully Readable.
Evensomeonewithareallybizarrestylecanbereadwithalittleefforttofigureoutwhatthatstyleis.
The problemcomeswhen You have MULTIPLE people OnA team, and THE SYLES getallmixedupsoittakes a lot moreefforttofigureoutwhatTHEFUCKisgoingon.
Linting is all about picking a style and sticking with it so the code doesn't end up with multiple personality disorder.
> Even though it's perfectly legal to disable linting for lines or files, most of the time when I do it, it's flagged by someone in review, and there's some discussion and I'm forced to rewrite and remove my disable and go back to whatever the linter was forcing. "These rules are there for a reason, and were put together by people with more experience and smarter than us - we shouldn't go disabling things whenever we want just because we don't like them or think we know better". (amalgamation of multiple comments from people stopping me disabling lint checks in specific situations).
When this happens, I think it should open a wider team conversation about whether that particular rule is actually worthwhile, or whether it goes against what your team wants and should be altered/disabled. Unfortunately, I have encountered a couple rules where the linter wasn't configurable enough to get what we wanted as a team, so there's definitely reason to allow per-instance disabling...
Re: GitHub Super Linter: one linter to rule them all
#274Earlier quoted context omitted.
Most autoformatters are under active development, and updates to them often causes changes in their behaviour. So you have to have all devs agree on the precise version of the formatter used, and even then you still need to do regular commits that contain nothing but a run of the newest version of the formatter on the codebase, which sadly destroys long term git blame.
this is a solved problem, pin your packages.
But you still have to update them every now and then otherwise you can't use new features of your language. Which gives you the issue of breakages again.
Re: GitHub Super Linter: one linter to rule them all
#275Earlier quoted context omitted.
Wouldn't having the autoformatter run as a pre-commit hook alleviate this issue? (This is assuming you had already cleaned up all of the currently checked in code with said autoformatter)
Prettier specifically annoys me to no end with this problem. If youre adding more attributes to a jsx component later and know it you might format to multiline early. It decides to undo your work and slow you down, because some arbitrary line length. Similarly, if you go over that line length, on something you want single line for readability of structure, it just straight up does what it wants. Im 100% on the auto f…
> It decides to undo your work
What you're missing here is that you're supposed to be using it all along, all the time. Format on save. Format on commit. Format on server pipelines. Format all the time. It can never 'undo' anything if it's what's providing the formatting in the first place.
Re: GitHub Super Linter: one linter to rule them all
#276Earlier quoted context omitted.
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…
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. No…
I find that if the auto formatter isn't dealing well with a section of code, it's usually an indication that the code architecture is off. Too clever, too verbose, too much nesting, trying too hard to make one-liners, etc.
There's a beauty that comes from simplicity, and code for matters, at least for me, are good of reminding me of that.
Re: GitHub Super Linter: one linter to rule them all
#277Great! 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…
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…
I don’t know. I feel formatting choice can carry information and removing that information for conformity might be not worth it.
Re: GitHub Super Linter: one linter to rule them all
#278They 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...
Re: GitHub Super Linter: one linter to rule them all
#279Earlier quoted context omitted.
Prettier specifically annoys me to no end with this problem. If youre adding more attributes to a jsx component later and know it you might format to multiline early. It decides to undo your work and slow you down, because some arbitrary line length. Similarly, if you go over that line length, on something you want single line for readability of structure, it just straight up does what it wants. Im 100% on the auto f…
> It decides to undo your work What you're missing here is that you're supposed to be using it all along, all the time. Format on save. Format on commit. Format on server pipelines. Format all the time. It can never 'undo' anything if it's what's providing the formatting in the first place.
Thats what im talking about. If you add text to a line, and it goes over a length, it will reformat a jsx element into about 5 lines instead of 1. Similarly, when you add more than it needs because you want consistency, or know youll add more, and the formatter runs, often it undoes your work.
Re: GitHub Super Linter: one linter to rule them all
#280Earlier quoted context omitted.
this is a solved problem, pin your packages.
But you still have to update them every now and then otherwise you can't use new features of your language. Which gives you the issue of breakages again.
I dont think people want to hear that there are still problems with autoformatting text.
Anyway, my point still stands, drop rules about line length and rules that care about inter line break positions and most of these problems go away.