Cannot run SwiftLint on any directory other than current working directory

[tahirmt]

New Issue Checklist

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

Describe the bug

I want to be able to run swiftlint lint Project/Directory and be able to have it read the config file located at Project/Directory/.swiftlint.yml and this does not work. It seems to not read the config file at all. If I pass in the config file using --config argument then it doesn't read nested .swiftlint.yml config files so that's not a possible alternative either.

Ideally, it should read the config files from the directory but if that's not possible then alternatively I would like a --working-directory argument so we can execute it from not the current directory. I have no option to cd to the working directory in my scenario as I am in a controlled environment.

Complete output when running SwiftLint, including the stack trace and command used

This is also irrelevant. It shows me thousands of violations for paths that I have ignored in my config file but it doesn't apply the config file.

Environment

• SwiftLint version (run swiftlint version to be sure)? 0.54.0
• Installation method used (Homebrew, CocoaPods, building from source, etc)? Homebrew
• Paste your configuration file:

The configuration file itself is not relevant.

[SoKamil]

In my case I want to traverse back two levels with swiftlint ../../ and it reads properties from .swiftlint.yml like disabled_rules but then it completely ignores properties where path matters like excluded or parent_config.

[mildm8nnered]

So ... ideally SwiftLint should work from anywhere, but there are definitely some spots in the code that assume that you will be executing at the top level of your project (maybe - at least it looks like that in the code), and there is also some complexity around how paths are treated on the command line, for historical reasons. It can be hard to change some of this behaviour, because existing users may be relying on them, even where they don't make sense when looked at afresh.

I think SwiftLint should read the .swiftlint.yml, just as though it was a nested configuration, although some settings may not work in that context (which sounds like it might be what's biting @SoKamil )- that is definitely something I can look into, time permitting.

[mildm8nnered]

So I'm interested to know what kind of environment you're in @tahirmt that won't let you cd. I think the best solution for you here may be a --working-directory option, if you really can't `cd'.

Right now swiftlint will assume that there should be a .swiftlint.yml in the current directory. If not, you will get the "default" configuration - no opt-in rules enabled, no default rules disabled. Merging that when SwiftLint finds your real .swiftlint.yml in a subdirectory is quite not the same as if it used the .swiftlint.yml from the start (which I think is what @SoKamil is experiencing).

Any thoughts @SimplyDanny ?

[tahirmt]

@mildm8nnered my scenario was writing a custom build tool plugin because I want to have a repo to get shared rules from. I wanted to use the tool and execute it in my working directory from the checkout path which is in a derived data. The current plugin is incredibly slow likely because it provides a list of files instead of directories so caching does not work and ends up adding minutes to every build. I want to support nested configs and the only way I can do that is by running sourcery from the root directory but due to how package plugins work the working directory is unchangeable and you don't get shell access.