Using the --path option ignores included/excluded paths in the config file

This change was made about 3 weeks ago: 3568245

It makes files passed with --path ignore the config file. However, we would like to be able to lint single files but make it also respect the configuration file. For example, if it's in the ignored files, linting would just succeed without even checking the file. Likewise if it is not in the included files.

Keeping this behaviour by default seems fine, but if the --config flag is also specified, it could overwrite the default behaviour?

[marcelofabri]

There're other reasons to pass a --config flag, so I don't think it would be a good idea to change the behavior based on that. We probably could have another flag to keep the old behavior, but IMO you should just filter the files before calling SwifLint.

Maybe @jpsim has more thoughts about this since he wrote that fix.

[jpsim]

Before 3568245, if you wanted to lint a single file like swiftlint lint --file MyIgnoredDir/File.swift, and MyIgnoredDir was ignored in the configuration, you'd get something like "Could not find any files to lint at 'MyIgnoredDir/File.swift'". If your specifying a single file in the command, it seems obvious that you want that file linted, no matter if it's ignored or not in the config...

So here is the scenario we have (and hopefully it's clear why we would like slight different functionality).

Our project is quite large, with over a thousand Swift files and well over a hundred thousand lines of Swift code. Our previous configuration was to run Swiftlint across the entire project on a build, however this caused problems since it would take well over 10 seconds to run. Our solution was to write a script which does a git diff and then lint only the files which have changed. This dropped the processing time from 10 seconds to a fraction of a second. The down side is that we have to build the inclusion and exclusion lists into the config file AND into this script now, which is something that we would rather avoid.

Alternatively, if there is a better solution to this scenario, we would be glad to hear it. (Something such as a flag which lints only the files mentioned under git diff and git diff --staged would be acceptable for example).

[jpsim]

I see. I think it would make sense to include a git staged/diff mode for SwiftLint.

[marcelofabri]

Wouldn't it make sense to run SwiftLint only on changed files during build (using git ls-files -m in a custom build step for example) but keep running it on all files when running via the terminal with swiftlint? You can always use the script you've created in the terminal as well.

While I agree that a git diff mode would be useful, I think that it shouldn't be part of SwiftLint itself as it's not a core part of a linter IMO. We'd have to be open to support other source control systems, for example.

PS: I might be misunderstanding something but I don't see why "The down side is that we have to build the inclusion and exclusion lists into the config file AND into this script now" would be true unless you've wanted that swiftlint lint always runs only in the changed files.

Having a diff mode sounds good (especially with support for other systems, but git would almost certainly be priority number 1).

For the last part of your message @marcelofabri, the scenario that we are trying to avoid is something like this:

One of our targets is in the exclusion list due to being older code that doesn't conform to our current standards, so we don't want to run the linter on it. We make a change to one of these files, the script to do the diff generates this as a changed file, and we run swiftlint on that file. Since the exclusion list is ignored, it is flagged with errors. The only way to avoid this currently is to not lint that file in the first place, which means we need to build our exclusion lists into this script as well as the swiftlint config.

[JimRoepcke]

I have the same issue as @dalemy, so having swiftlint respect the exclusion list even with a --path parameter would be appreciated, even if we have to add another parameter like --respect-config-exclusions to get it to work.

But perhaps it could accept, on stdin, a list of paths to lint (and it would apply the config exclusions to that list before processing)? Then instead of running swiftlint N times we just run it once and save the cost of the program starting up for each path.

[sundeepgupta]

We're running into this where we want to pass the --path option but have it still respect an excluded file. I thought a work around would be to disable linting for an entire file via a // swiftlint:disable:all for example. Is there such a solution?

@sundeepgupta I don't think that's a good solution, since it removes a lot of control. For instance, if someone decideds to check in a cocoapod, then they will have to modify all files there to have this. In our case, we have lots of autogenerated files which get checked in, and they would all need to have this added.

[sundeepgupta]

@dalemy completely agree. I was just wondering if there was a way to disable an entire file easily as a temporary workaround for our project.