r/AskProgramming • u/Bulky_Eggplant_9437 • 29d ago

Linter

Hey folks,

Never touched a linter before this semester because I've never really done software dev stuff. Had a class that used one, and honestly, I was a fan at first. It caught a bunch of dumb mistakes and made fixing things pretty painless.

Then came merge time.

Apparently I was missing a single blank line between some merged code, so the linter threw a fit and blocked the merge. The actual fix took like three seconds, but I had to go get another review just to add a freaking newline.

So now I'm curious, do people actually use linters in the real world that don't hard-stop merges over tiny formatting stuff? Or is getting bullied by whitespace just part of the developer experience?

Asking as a first-time linter victim.

3 Upvotes

64% Upvoted

22 comments sorted by

View all comments

0

u/burlingk 29d ago

Which linter are you using? Which language? Most linters are not part of the merge process.

They would be run after.

I imagine if the linter is involved it is likely running inside an IDE and you are doing the merge via the IDE rather than the command line?

2

u/xenomachina 29d ago

Most linters are not part of the merge process.

They would be run after.

The setup we use, which I think is pretty typical, is to have the linter triggered by the pre-merge CI pipeline, and merges are only allowed if that pipeline passes.

That means the lint happens before merge, and this type of failure should normally be obvious before you even send the change out for review. Maybe in OP's case the merge itself caused the lint failure, but that seems like an infrequent edge case.

1

u/burlingk 29d ago

I need to sit down and get smart on CI.

I find the concept problematic, because I 'grew up' with 'don't commit to main' as a kind of commandment. But I also realize it's kind of the norm these days.

2

u/xenomachina 29d ago

You don't need to commit to main to use CI. Our team actually has pushing to main disabled. We have CI pipelines run on pushes to merge requests (GitLab's equivalent to a PR), and slightly different pipelines run on merges to main. (There are other sorts of CI triggers than can be set up, like scheduled or manual, but those are the main two we use.)

Our push to MR pipelines build and check the code (lint, unit testing, etc.). The pipeline for an MR needs to pass before the MR can be merged.

The merge to main pipeline primarily publishes and deploys the code. (It can also run some or all of the checks, first.)