Discover Top Posts Tagged with #swiftlint

SwiftLint Configuration Example

For those wondering about some of the less-obvious parts of a SwiftLint configuration file, here's an example file which hopefully spreads some light on how to configure some of the more complex rules.

excluded Rules

The excluded section of the configuration file expects a list of paths to exclude from linting. Paths are relative to the directory from which SwiftLint was called, so make sure that you include paths relative to the location of the file that invokes SwiftLint. For example:

When running from the command line, the excluded paths need to be relative to the location you run the command from.

When using Danger, the excluded paths need to be relative to the location of the Danger file which invokes SwiftLint, e.g. Danger_postclone.

For a file structure like this:

Use the following configuration to enable exclusion of any files under Libraries when using Danger:

# .swiftlint.yml excluded: - ../Libraries

Or this configuration when using the command line from the MyProject directory:

# .swiftlint.yml excluded: - Libraries

Adjusting Severity Levels

Run $ swiftlint rules to get a table with all of the rule identifiers you might want to use in your configuration file.

To work out how to adjust rule configurations, look under the configuration column.

Simple Rules

If the contents of the column just says "warning" or "error", the only thing that can be adjusted for that rule is the severity. The adjustment syntax for this kind of adjustment is:

{rule_identifier}: {desired_severity}

For example, to downgrade the closing_brace rule to a warning instead of an error:

# .swiftlint.yml closing_brace: warning

Or to upgrade the class_delegate_protocol to an error instead of a warning:

# .swiftlint.yml class_delegate_protocol: error

Complex Rules

Some rules have more attributes that can be configured than just the severity. The names of these attributes will be specified in the rules table.

If you are trying to configure complex rules incorrectly, you may be getting a warning when running $ swiftlint rules like:

Invalid configuration for 'statement_position'. Falling back to default.

Complex rules do not accept the same configuration syntax as simple rules.

This is what the rules table says for the colon rule:

| colon | warning, flexible_right_spacing: false, apply_to_dictionaries: true |

In this case, you can override the severity and the attributes like this:

# .swiftlint.yml colon: severity: error flexible_right_spacing: true apply_to_dictionaries: false

If you only want to override the severity on these complex rules, you still need to use the severity: syntax - you can't just do colon: error as with simple rules.

Other rules can be more complex, like nesting:

| nesting | (type_level) w: 1, (statement_level) w: 5 |

For the nesting rule, you can configure the severity levels of type-nesting and statement-nesting separately, and you can also define what level of nesting triggers a warning and what level of nesting triggers an error.

The default configuration shows that a warning will be triggered by 1 level of type-nesting and at 5 levels of statement-nesting, and there are no levels of nesting which will trigger an error.

You can change this configuration to (for example) trigger type-nesting warnings at 2 levels of nesting, errors at 3 levels, and statement-nesting warnings at 3 levels of nesting, errors at 5 levels.

# .swiftlint.yml nesting: type_level: warning: 2 error: 3 statement_level: warning: 3 error: 5

#swiftlint #danger #configuration #ci #continuous integration #stylecop #swift #yaml