Writing custom ESLint rules for your picky developers

Sometimes writing a custom rule makes sense, but it should be an exception and not the rule. Otherwise, you risk creating a sub-dialect only your team knows. That becomes a problem both for new hires, which have to take more time to ramp up, and for current dev switching jobs as they'll have a hard time abandoning what they learned.

That's why I like sticking as close as possible to AirBnB's guide[0], not because it's better than anything else, it's just that most developper seem to agree on it and it's familiar to most dev.

[0]: https://github.com/airbnb/javascript

One danger of having a bunch of custom eslint rules is that you may be papering over weak abstractions in your codebase. Sometimes it's a problem with lack of macros (or a powerful type system) but other times rethinking the way you are using libraries can be a bigger win for maintainability.

Rather than trying to impose one style over another, (or worse, pretending one is standard and everyone else is wrong), it saves time to just let your devs set their editors to automatically open in the style they think best with (because the reason picky devs argue about syntax is to avoid frustration and losing focus when reading code), and let the commit hook format back to a common style.

Tools help you get the job done, not get in the way.

Setting up https://standardjs.com to format on save really helped me overcome my pointless formatting preferences, although gofmt was the catalyst.