SwiftLint: Adding --strict does not log or display linter violations as errors

It is possible to treat all swiftlint warnings as errors by modifying the swiftlint output like this:

#!/bin/bash

# Make the script return a failure code if any of the commands executed in the middle fail (even if they are piped)
# For more info, see: https://stackoverflow.com/questions/821396/aborting-a-shell-script-if-any-command-returns-a-non-zero-value
set -e
set -o pipefail

swiftlint lint --strict | sed 's/warning:/error:/g'

Or in case you are using swiftlint from cocoapods:

${PODS_ROOT}/SwiftLint/swiftlint lint --strict | sed 's/warning:/error:/g'

@acecilia 🤦‍♂️ Thanks! Turns out I can’t read.

I enthusiastically agree with everything you suggested, Scott.

To me, doing rule-scope only seems the most practical. It will provide the desired behavior (though potentially more onerous configuration), it fits with what we are already doing with ViolationLevelRule, and it fits a wider spectrum of uses cases.

&

At rule scope, we can create a new protocol, say WarningOrErrorRule, to provide standard conformance to ConfigurableRule, and allow people to add a flag to their .swiftlint.yml files to indicate violation severity.

I think that’s the way to go. And I think a protocol, and perhaps a new section in the .yml file with ‘error-level-violations’ and ‘warning-level-violations’ might be a nice structure there. That’s without me actually trying to implement this yet. But from my exploration of the library, that seems good.

As far as the --strict flag goes…hm…

In the interim (before changes are potentially made to the way rule violations can be configured and are displayed) I do think more documentation on how to exit a build when style rules are violated would be great, and is probably relevant to many teams using SwiftLint.

Looking at SwiftLint initially it seemed like maybe SwiftLint hooked back into some part of the Swift compilation process/ sent errors to SourceKit somewhere to report violations, rather than just printing them. Maybe a sentence in the readme, or a small sample script in the same way there is a sample .yml in this repo. I’m happy to contribute mine.

Of course!

The primary reason is cultural.

People do not take warnings as seriously as they should. Errors, obviously, have to be dealt with immediately. Warnings do not. This isn’t because they do not believe in or write high quality code. There are lots of reasons why a project might have a few lingering warnings.

To me, the point of linting is introducing a passive tool that communicates a team’s values and improves their code.

Introducing warnings into a project means that a linter becomes not actually a totally passive tool. Its usage then requires some policing by other team members – not because people are lazy, but because they have to decide how to allocate their time, and sometimes resolving warnings can’t be done in a certain time frame. Also, if an app already has a few warnings (see explanation for reasons why below) they can easily forget whether or not they added warnings until they merge a PR and see if the CI tool suggests that they introduced new warnings into the project.

There are lots of reasons why a code base might already have some warnings – these include needing to integrate 3rd party code which introduces warnings – sometimes unavoidable on large apps owned by mid sized or large companies – and the fact that fast moving teams sometimes just need to leave errors in their code temporarily. Moreover, apps that have been in development for many years may have legacy code with warnings that people have not yet found time to fix. That’s not the case on the app I work on, but I can absolutely see that happening on other teams. For that reason, having linter violations displayed as warnings does not have the kind of impact you would hope for.

In my view, linter violations are far more likely to be dealt with if SourceKit/the compiler provide errors rather than warnings in the IDE.

If you implement more fix-its in the SwiftLint project I think this point still stands – I would like to see errors in my project where linter rules are not respected, and suggestions for changes, like what’s built into Xcode using SourceKit.

Note: This whole comment is based on a model where the transition to a SwiftLinted project is first only performed on files that have a diff in a developer’s current branch, using a build script, and then on the entire project potentially. This helps mitigate the fact that a project that only shows errors, not warnings after being linter, would require potentially tons of changes in order to build.

What do you think about this, JP? I’m really interested in your opinion, and in your reasoning for initially not introducing this functionality.