I use custom linters as a “continuous codemod” that transform old code and engineer habit in form X to new form Y. Combined with a way to “ratchet” the number of rule violations towards zero, we can gradually and relatively painlessly roll out any number of whole codebase migrations in parallel over weeks or months.

Two examples:

- we have an API like dbModel.getValue() that subscribes the current view to any change in an entire database row. We noticed this lead to UI performance issues from components over-rendering. To deprecate, I wrote a rule to transform dbModel.getValue().specificProp to dbModel.getSpecificProp(). We can’t remove the getValue method since there’s times you really do need it, but we can automatically switch new code written to a more performant specific call for many cases.

- We use a lint rule to enforce that API endpoints and queue worker jobs have ownership and monitoring rules specified. We could use the type system to strictly enforce this, but we want to support gradual migration as well as suggest some inferred values based on the identity of the author. Using a lint with ratcheting means newly added cases are enforced but easy to add, and old cases can/will adopt over time.

I want to find the time to write a blog post about this, I think it’s a pretty handy pattern.