0

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.

Improve this question
6
  • 1
    Changing the version of the linter doesn't necessarily mean changing the rules. If it does, you can include an update to the configuration to mean nothing else changes.
    – jonrsharpe
    Apr 27, 2020 at 18:21
  • What do you mean with "reformatting the code when you update a library"? Do you mean that you reformat the code of external dependencies to conform to your local rules? Or that an update to eslint/prettier comes with a new setting for how the project should be formatted?
    – Bart van Ingen Schenau
    Apr 28, 2020 at 6:09
  • the second, @BartvanIngenSchenau. I guess I might expressed bad when I say eslint. We have a set of dependencies for our eslint config package, and I guess some of these dependencies bring new set of rules everytime we update it, which implicates in us having to reformat the code to suit the new rules, or override them. It's a very painful process.
    – sergioviniciuss
    Apr 28, 2020 at 7:37
  • Then the problem seems to be that you are using someone else's configuration, rather than creating your own configuration that will only be updated explicitly and intentionally. But I'm not experienced enough with eslint to tell you how to do this :/
    – amon
    Apr 28, 2020 at 7:48
  • 1
    Are you updating the airbnb config dependency? Because if so the only updates that can contain are changes to the rules. If you like the rules of the current version, don't update it. And if you do want to update, check the changelog for what updates you're taking on.
    – Stan Lindsey
    Apr 28, 2020 at 21:26

1 Answer 1

Reset to default
2

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.

Improve this answer
1
  • Thanks for the inputs, Bart! What you're saying makes total sense. It doesn't make sense to me to keep introducing new rules all the time if the team is happy with the current ones, and if we want to introduce new ones, we should discuss and align before.
    – sergioviniciuss
    Apr 29, 2020 at 8:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.