When does it make sense to update eslint/prettier?

Question

I have the following setup:

• different teams
• shared eslint config (that imports airbnb rules as a basis).

Whenever a developer decides to update libraries, if eslint/prettier have updates, it's a pain. The main reason is becuase normally eslint or prettier are introducing new rules. If we update these libraries, they implicate, most of the times, in reformatting the entire code. I personally don't think this is a good practice, because:

1. it clutters the log.
2. you're adding new rules that the teams are not aware (impacts can be huge)
3. Steps 1 and 2 will always repeat whenever you update the libs.

Giving the step 3 I mentioned, it makes me wonder if it makes sense to update these libs.

When we didn't have anything, following airbnb rules was great. But does it make sense to keep including new rules and reformatting the code whenever you update a library. (for instance, we have establish a process of updating the frontend libraries once a month to avoid having deprecated libs. Not updating the eslint rules and waiting longer proved to be even worse.

I wanted to know how do you guys handle it and what are the best practices on it.

Since this is more process-related question, software engineering seems to be the right place to ask.

Answer 1

When you first introduce a linter, style checker or similar tool in your build pipeline that performs additional checks and/or reformats the code, then the number of options you can/need to set is daunting and it is a good idea to copy the configuration from another project (or company) whose configuration settings seem to give decent results.

But after that first copy, you as a team (or group of teams with an intentionally shared configuration) must own that configuration. This means that if there is an update to the tool that introduces new rules, those rules must initially be disabled when the update is added to your repository. After the update, you can discuss with all the users of the configuration if it makes sense to enable some of those new rules.

If enabling a new rule causes a style-change to the code, then there should be a single commit where that rule is enables and its effects to the existing codebase are applied, and only those changes. That way it is better identifiable where the large diff in the code came from.