Having a good process to update your tools is very important, specially for those that affect directly your code. I’ve talked about how I update swiftformat and this post will discuss my update process for SwiftLint.

At a high level the process is very similar since the goals are the same: to have full control of what rules are run over our code.

The process starts very similar as with swiftformat. First, I check and track the time it takes to run the current version of the tool to detect big regressions. Second, I check the changelog and take a quick look at what changes I will have to work trough. Then I update the binary and start the process.

In this case, I rarely go one version at a time. This is because the linter never touches our code, so I’m less afraid of regressions on a specific version.

One important detail is that I have the linter configured to only run the rules I enable manually, by using the only_rules option. This means that not even the default ones will run without my approval. As with the previous post, I keep all rules in the configuration, including the disabled ones, which have a friendly comment explaining why they are disabled.

To see what changes have happened, I run this command:

./swiftlint rules --config ./swiftlint.yml > ./swiftlinttable.txt

This saves a table with all the rules in our git repo. The git diff makes it really easy to see the new rules, and because they are all disabled, I can easily go one by one and check them out.

Conclusion

That’s it. As you can see, this one is a little more straightforward thanks the keeping a list committed in gif.

The two important things from this system are:

1. Use only_rules to manually enable rules instead of relying on defaults.
2. Commit the list of rules in git to make use of the diff.

I hope you learned a bit from reading my process and if you have a better one, make sure to reach out 😉.