Swiftlint: Disable SwiftLint via config file

[fredpi]

New Issue Checklist

• [x] Updated SwiftLint to the latest version
• [x] I searched for existing GitHub issues

Environment

• SwiftLint version: 0.25.0
• Installation method used: Homebrew
• Config file:

included:
- MyDir

• Xcode 9.3

Request

I'd like to have an option to quickly disable SwiftLint entirely for a limited time. Currently I'm adding a exit 0 prefix to the shell script invoking SwiftLint, but that's not cool if working with others who presumably wouldn't think of that first.

Is there currently any way to add a temporary-disable flag to the config file?

If not so, I'd suggest this as a feature. Sometimes (like now, that I'm having lots of SwiftLint issues with the 4.1-compatible version not being out by now) it would be useful to be able to quickly disable SwiftLint via the config file and without manipulating the shell script.

[marcelofabri]

You could change included to excluded for example. Or maybe using whitelist_rules with an empty array.

[fredpi]

Thanks for replying.

Those are all valid options, yet, it’s not entirely clear what’s the suggested way to do it. If it’s just about a single person, there’s no issue choosing one of these options or the exit 0 approach I came up with. However, with open source projects or in a large team, I think there should be a more clear way to do it.

The question is, whether there is any such way at all. Adding a enable / disable flag to the config file could be also confusing for people not familiar with it...

What do you think of some kind of flag that would by default generate one single warning Remember to turn SwiftLint back on, and optionally also disable this single warning at all?

[SDGGiesbrecht]

While discussion continues about possibly embedding this into SwiftLint...

In the meantime, you can edit the invoking script to your heart’s content, which means you can have it check whatever you want before deciding whether to run SwiftLint.

You could split based on:

• environment variables (then $ set .../$ unset ...),
• Xcode build configurations (with/without),
• the presence or absence of a gitignored file called skip‐lint in the project directory (then $ touch skip‐lint/$ rm skip‐lint)
• a more general project configuration file,
• or even query the local weather and only lint if it is sunny outside 😄.

[marcelofabri]

I understand that there's a use case for it, but I don't believe that it's worth adding this extra complexity to the tool as the workarounds are usually good enough.

[fredpi]

@SDGGiesbrecht Thanks for those suggestions, I will definitely give them a try 👍

[fredpi]

@marcelofabri I get your point here, however it would be nice to have a suggested way to do it, or do you think this would also blow things up too much?

Maybe one could change the invoking script according to any of @SDGGiesbrecht's suggestions

[marcelofabri]

@fredpi You mean just updating the README to cover this use case? If so, PRs are welcome 👍

[brennanMKE]

I wanted to do the same because I am working on an Xcode project which has many sub-projects which run SwiftLint every time even when I am not changing the code in those projects.

Here is my simple solution. When I want to disable SwiftLint I will run touch ~/.swiftlint-disable which creates an empty file at that location in my root folder. The snippet below goes into my Build Script for SwiftLint at the start. If the file exists "-f" then it exits with a 0, meaning all is good. When I want to enabled SwiftLint again I can simply run rm ~/.swiftlint-disable. I just ran my long build with this file in place along with the code snippet below and now build is much faster.

if [ -f ~/.swiftlint-disabled ]; then
  exit 0
fi

[fredpi]

@brennanMKE Interesting solution, in that creating a simple file is a global thing (in contrast to having a bool in each run script phase).

I'd be in favour of amending the suggested SwiftLint invocation script according to this suggestion, yet with one little change: I don't think the created "disable file" should be hidden. For me, disabling SwiftLint via the run script phase may be a quick temporary change that should easily be visible / understandable to everyone participating. Having a hidden file being responsible to stop SwiftLint from running wouldn't be in-line with this goal.

What do you think about a) "recommending" this SwiftLint invocation script globally b) using a hidden or visible file, @marcelofabri @SDGGiesbrecht?

[SDGGiesbrecht]

What do you think about a) “recommending” this SwiftLint invocation script globally b) using a hidden or visible file[?]

I have no meaningful thoughts to add. Ironically, it would actually be the least experienced user who can best tell which example is most useful and least confusing.

[brennanMKE]

My adjustment was quick and easy for me. I am not sure I would recommend it for every team. What I could even do is schedule a cron job which deletes that file every morning so I do not go long without running SwiftLint.

Another option to speed up builds, could be to define a cool down period for SwiftLint. Perhaps if it was just run it could defer running for a build which is at least 30 minutes later. When it delays my build by minutes each time that would save me a lot of time each day. And most of the time I am not looking to fix each warning. I am dealing with a lot of legacy code so these warnings have been there a while and are not going away quickly.

[fredpi]

I see adding this as a recommended way to temporarily disable SwiftLint may be quite irritating as not everyone will have a look at the run script phase or suspect that a empty file in the directory may keep SwiftLint from running.

Therefore, the best option would probably be for each team to define how they do this if needed somehow instead of a general recommendation.