Exclude Pods and Carthage directories by default

[robmaceachern]

New Issue Checklist

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

Enhancement Request

I think that the Pods and Carthage directories should be excluded from SwiftLint by default.

Flagging linter warnings/errors on dependencies isn't a very useful or commonly needed feature. Most sample .swiftlint.yml files that I've seen manually exclude these directories (examples: 0, 1, 2). This should be a built-in default which can be overridden with included if needed for some reason.

At least with Cocoapods, excluding the Pods directory by default would simplify the initial integration of SwiftLint into the project. Currently, the initial setup goes something like:

• Add pod 'SwiftLint'
• Add the "${PODS_ROOT}/SwiftLint/swiftlint" to a build phase
• Build project, which fails due to third party linter violations
• Google "swiftlint config sample"
• Add .swiftlint.yml and excluded: - Pods

It also makes running an initial or one-off autocorrect more cumbersome than it needs to be.

Related to #1637. This was mentioned also in #6 but the issue was closed with the addition of the exclusion options to .swiftlint.yml.

Environment

• SwiftLint version (run swiftlint version to be sure)? 0.26.0
• Installation method used (Homebrew, CocoaPods, building from source, etc)? Cocoapods

[fabb]

Maybe rather create a swiftlint init command (similar to pod init) that creates a default .swiftlint.yml configuration file that already includes excluded: - Pods?

[sindresorhus]

@fabb It's easy enough to add it manually. The point here is to reduce boilerplate and optimize for the common case.

[robmaceachern]

@fabb I think some kind of command that generates a .swiftlint.yml could be useful, particularly if there was some way it could make discovering opt-in rules better. I still think the Pods exclusion should be a SwiftLint default though :)

[fabb]

I‘m not against it, just wanted to point out a possible alternative.

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. Please comment to prevent this issue from being closed. Thank you for your contributions!