Danger Swift plugin for SwiftLint. So you can get SwiftLint warnings on your pull requests!

(Note: If you're looking for the Ruby version of this Danger plugin, it has been moved here.)

Install and run Danger Swift as normal and install SwiftLint in your CI's config file. Something like:

dependencies:
  override:
  - npm install -g danger # This installs Danger
  - brew install danger/tap/danger-swift # This installs Danger-Swift
  - brew install swiftlint # This is for the Danger SwiftLint plugin.

Then use the following Dangerfile.swift.

// Dangerfile.swift

import Danger
import DangerSwiftLint // package: https://github.com/ashfurrow/danger-swiftlint.git

SwiftLint.lint()

That will lint the created and modified files

If you want the lint result shows in diff instead of comment, you can use inline_mode option. Violations that out of the diff will show in danger's fail or warn section.

SwiftLint.lint(inline: true)

You can also specify a path to the config file using configFile parameter and a path to the directory you want to lint using directory parameter. This is helpful when you want to have different config files for different directories. E.g. Harvey wants to lint test files differently than the source files, thus they have the following setup:

SwiftLint.lint(directory: "Sources", configFile: ".swiftlint.yml")
SwiftLint.lint(directory: "Tests", configFile: "Tests/HarveyTests/.swiftlint.yml")

By default, only files that were added or modified are linted.

It's not possible to use nested configurations in that case, because Danger SwiftLint lints each file on it's own, and by doing that the nested configuration is disabled. If you want to learn more details about this, read the whole issue here.

However, you can use the lintAllFiles option to lint all the files. In that case, Danger SwiftLint doesn't lint files individually, which makes nested configuration to work. It'd be the same as you were running swiftlint on the root folder:

SwiftLint.lint(lintAllFiles: true)

By default, Danger SwiftLint runs swiftlint assuming it's installed globally. However, there're cases where it makes sense to use a different path. One example would be if you've installed SwiftLint using CocoaPods.

To use another binary, you can use the swiftlintPath option:

SwiftLint.lint(swiftlintPath: "Pods/SwiftLint/swiftlint")

If you find a bug, please open an issue! Or a pull request 😉

No, seriously.

This is the first command line Swift I've ever written, and it's the first Danger Swift plugin anyone has ever written, so if something doesn't work, I could really use your help figuring out the problem.

A good place to start is writing a failing unit test. Then you can try to fix the bug. First, you'll need to fork the repo and clone your fork locally. Build it and run the unit tests.

git clone https://github.com/YOUR_USERNAME/danger-swiftlint.git
cd danger-swiftlint
swift build
swift test

Alright, verify that everything so far works before going further. To write your tests and modify the plugin files, run swift package generate-xcodeproj. Open the generated Xcode project and enjoy the modernities of code autocomplete and inline documentation. You can even run the unit tests from Xcode (sometimes results are inconsistent with running swift test).

One place that unit tests have a hard time covering is the integration with the swiftlint command line tool. If you're changing code there, open a pull request (like this one) to test everything works.

There are tonnes of ways this plugin can be customized for individual use cases. After building the Ruby version of this plugin, I realized that it's really difficult to scale up a tool that works for everyone. So instead, I'm treating this project as a template, that you to do fork and customize however you like!

1. Fork this project.
2. Change the import DangerSwiftLint package URL to point to your fork.
3. After making your changes to the plugin, push them to your fork and push a new tag.

Because you need to tag a new version, testing your plugin can be tricky. I've built some basic unit tests, so you should be able to use test-driven development for most of your changes.

If you think you've got a real general-purpose feature that most users of this plugin would benefit from, I would be grateful for a pull request.

#MIT4Lyfe

Your feeling when you lint your swift code