Why is it so hard to add a new linter to an existing code base?
The challenge is usually that it’s all or nothing. You have two options:
<ul>
<li>Add a new linter and fix all the problems that come up. Difficult upfront cost to justify.</li>
<li>Add a new linter but ignore all the problems it produces and say “I’ll fix it later”. Later being <code>// TODO: fix this | blame: me. 3 years ago</code>.</li>
</ul>
I would love to hear about the challenges and pushback you’ve faced and how you justify the approach to your org.
We wrote <a href="https://trunk.io/blog/reasons-developers-hate-linters" target="_blank" rel="noopener nofollow">a blog</a> about eating the elephant one bite at a time a while ago because an all-or-nothing approach to code quality is not a practical approach.
We’ve built a tool, <a href="https://docs.trunk.io/code-quality/usage" target="_blank" rel="noopener nofollow">Code Quality</a>, since then that acts as a meta linter to lint only lines changed to help with the problem, but we’re still seeing other issues with linter adoption.
<ul>
<li>Standardizing cross repos</li>
<li>Siloing and inconsistent config across teams</li>
<li>Changing code standards as languages evolve.</li>
</ul>
I’m also curious what issues you’ve faced with standardizing code quality in your org

Hi, Trunk makes developer tools to solve problems developers hate.

But we also love sharing about what we learn along the way as we speak to engineering leaders!

Trunk.io

Integrating a new linter into an existing code base often presents an all-or-nothing challenge: either fix all detected issues upfront or ignore them for later, risking significant technical debt. A meta linter tool that only lints changed lines can alleviate this hurdle but still faces issues such as standardization across repositories and evolving code standards. The discussion includes community experiences and solutions for these common challenges.

Chore: Add new linter and formatter

Not linting but I am in the process of migrating the company’s mid-size react native app of around 90 screens from js class based component to typescript functional component. The PM of course doesn’t care about it but it is essential to improve code quality and catch bugs early.

My approach is only lint the component I work with, not only change files. So it’s ok for planning because the effort is acceptable and the improvement overall make sense
Every tool should have ability to only lint some folder/pattern/… so just add more cover spaces every time you have plan to implement/fixing any thing

At first, I thought this post was about Biome. After reading it, I realize that this approach is even better than having a local linter. I’ll give it a try.

Chore prefix is the right one or should use refactor: chore … ? I’m learning the conventions :D

Whether projects move effectively or not is, in my experience, dependent on how well they are understood.
A dev with a coherent idea is a powerhouse; They’ve thought this through, they want this to work, they know where to start. The upfront cost is lower, and often offset by eagerness.
My migration success stories always revolve around giving devs enough context and freedom, then letting them do their jobs. Go in, set new ground rules, put facts on the ground, move on. Easier with backend than frontend, but not impossible on either.
Not knocking the tool (or implicit advertising?), but replacing a human element with processes and tools is a bad idea.