If you'd like to write a SwiftLint rule but aren't sure how to start,

All changes, no matter how trivial, must be done via pull request. Commits

should never be made directly on the`main` branch. Prefer rebasing over

merging`main` into your PR branch to update it and resolve conflicts.

All changes, no matter how trivial, must be done via pull requests. Commits

should never be made directly on the`main` branch. If possible, avoid mixing

different aspects in one pull request. Prefer squashing if there are commits

that are not reasonable alone. To update your PR branch and resolve conflicts,

prefer rebasing over merging`main`.

_If you have commit access to SwiftLint and believe your change to be trivial

and not worth waiting for review, you may open a pull request and merge

and not worth waiting for review, you may open a pull request and merge it

immediately, but this should be the exception, not the norm._

1. Select the "swiftlint" scheme

1.`cmd-opt-r` open the scheme options

1. Select the "swiftlint" scheme.

1.`cmd-opt-r`toopen the scheme options.

1. Set the "Arguments Passed On Launch" you want in the "Arguments" tab. See

available arguments[in the README](https://github.com/realm/SwiftLint#command-line).

1. Set the "Working Directory" in the "Options" tab to the path where you would like

to execute SwiftLint. Afolder that containsswift source files.

1. Hit "Run"

to execute SwiftLint — afolder that containsSwift source files.

1. Hit "Run".

|Arguments|Options|

|-|-|

|||

Then you can use the full power of Xcode/LLDB/Instruments to develop and debug your changes to SwiftLint.

1. Use the produced`swiftlint` binary from the command line, either by running`swift run [-c release] [swiftlint] [arguments]` or by invoking the binary directly at`.build/[release|debug]/swiftlint`

1.[Optional] Attach LLDB:`lldb -- .build/[release|debug]/swiftlint [arguments]`

1.For debugging, attach LLDB:`lldb -- .build/[release|debug]/swiftlint [arguments]`

SwiftLint supports building via Xcode and Swift Package Manager on macOS, and

with Swift Package Manager on Linux. When contributing code changes, please

ensure that allthree supported build methods continue to work and pass tests.

ensure that allfour supported build methods continue to work and pass tests:

$ xcodebuild -scheme swiftlinttest -destination'platform=macOS'

$ swifttest

$ make docker_test

xcodebuild -scheme swiftlinttest -destination'platform=macOS'

swifttest

make bazel_test

make docker_test

New rules should be added in the`Source/SwiftLintBuiltInRules/Rules` directory.

Rules should conform to either the`Rule` or`ASTRule` protocols.

Prefer implementing new rules with the help of SwiftSyntax. Look for the

`@SwiftSyntaxRule` attribute for examples and use the same on your own rule.

New rules should conform to either`Rule` or`OptInRule` depending on whether

they shall be enabled by default or opt-in, respectively.

All new rules or changes to existing rules should be accompanied by unit tests.

Whenever possible, prefer adding tests via the`triggeringExamples` and

`nonTriggeringExamples` properties of a rule's`description` rather than adding

those test cases in the unit tests directly. This makes it easier to understand

what rules do by reading their source, and simplifies adding more test cases

over time. This way adding a unit test for your new Rule is just a matter of

adding a test case in`RulesTests.swift` which simply calls

`verifyRule(YourNewRule.description)`.

over time. With`make sourcery`, you ensure that all test cases are automatically

checked in unit tests. Moreover, the examples added to a rule will appear in the

rule's rendered documentation accessible from the

[Rule Directory](https://realm.github.io/SwiftLint/rule-directory.html).

For debugging purposes examples can be marked as`focused`. If there are any

focused examples found, then only those will be run when running tests for that rule.

For debugging purposes, examples can be marked as`focused`. If there are any

focused examples found, then only those will be run when running all tests for that

rule.

nonTriggeringExamples: [

Example("let x: [Int]"),

Example("let x: [Int: String]").focused()//Only this one will be run in tests.

],

triggeringExamples: [

Example("let x: ↓Array<String>"),

Example("let x: ↓Dictionary<Int, String>")

]

Every rule is configurable via`.swiftlint.yml`, even if only by settings its default

severity. This is done by setting the`configuration` property of a rule as:

If your rule supports user-configurable options via`.swiftlint.yml`, you can

accomplish this by conforming to`ConfigurationProviderRule`. You must provide a

configuration object via the`configuration` property:

var configuration= SeverityConfiguration<Self>(.warning)

If a rule requires more options, a specific configuration can be implemented

and associated with the rule via its`configuration` property. Check for rules providing

their own configurations as extensive examples or check out

* There are several provided`RuleConfiguration`sthatcover the common patterns like

specificallyforyour rule.

for a rulethatallows severity configuration,

fora rule that allows name evaluation configuration.

See[`ForceCastRule`](https://github.com/realm/SwiftLint/blob/main/Source/SwiftLintBuiltInRules/Rules/Idiomatic/ForceCastRule.swift)

for a rule that allows severity configuration,

for a rule that has multiple severity levels,

for a rule that allows name evaluation configuration:

Configuring them in`.swiftlint.yml` looks like:

force_cast:warning

file_length:

excluded:id

`Issue.unknownConfiguration(ruleID:Parent.identifier)`.

We follow the same syntax as CocoaPods' CHANGELOG.md:

1. Install Homebrew:https://brew.sh

1. Install Homebrew:<https://brew.sh>

1. Install Buildkite agent and other tools via Homebrew:

1. Install latest Xcode version:`xcodes update && xcodes install 14.0.0`

1. Configure and launch buildkite agent:`brew info buildkite-agent`/