Prints out something like this on macOS:
```
Version: 0.49.0-rc.1
Build ID: B43931F3-D096-3704-B41C-FC40673A3F96
```
This can be used to determine if two `swiftlint` executables are
identical.
This change makes it possible to add native custom rules when building
SwiftLint via Bazel (possible as of
https://github.com/realm/SwiftLint/pull/4038).
First, add a local bazel repository where custom rules will be defined
to your project's `WORKSPACE`:
```python
local_repository(
name = "swiftlint_extra_rules",
path = "swiftlint_extra_rules",
)
```
Then in the extra rules directory, add an empty `WORKSPACE` and a
`BUILD` file with the following contents:
```python
filegroup(
name = "extra_rules",
srcs = glob(["*.swift"]),
visibility = ["//visibility:public"],
)
```
To add a rule (for example, `MyPrivateRule`) add the following two
files:
```swift
// ExtraRules.swift
func extraRules() -> [Rule.Type] {
[
MyPrivateRule.self,
]
}
```
```swift
// MyPrivateRule.swift
import SourceKittenFramework
import SwiftSyntax
struct MyPrivateRule: ConfigurationProviderRule {
var configuration = SeverityConfiguration(.error)
init() {}
static let description = RuleDescription(
identifier: "my_private_rule",
name: "My Private Rule",
description: "This is my private rule.",
kind: .idiomatic
)
func validate(file: SwiftLintFile) -> [StyleViolation] {
// Perform validation here...
}
}
```
Then you can reference the rule in your configuration or source files as
though they were built in to the official SwiftLint repo.
This means that you have access to SwiftLintFramework's internal API.
We make no guarantees as to the stability of these internal APIs,
although if you end up using something that gets removed please reach
out and we'll make a best effort to maintain some level of support.
This PR also improves the linter cache on macOS to make it correctly
invalidate previous results when custom native rules are edited. This
even works when doing local development of SwiftLint, where previous it
was necessary to use `--no-cache` when working on SwiftLint, now the
cache should always work.
Co-authored-by: Keith Smiley <keithbsmiley@gmail.com>
This bumps the minimum version required to build SwiftLint to 4.2. The primary motivating factor to drop support for Swift 4.0-4.1.x is that SwiftLint now uses CryptoSwift, which requires 4.2.
* Add changelog entry
* Remove --allow-warnings flag from CocoaPods commands
* Update CryptoSwift to 0.13.0
* Migrate to Swift 4.2
* Remove CircleCI tests for Swift < 4.2
* Update English and Chinese README
Korean README doesn't yet have a version table like this.
* Update gems
* Add changelog entry for fixed compiler warnings
* Update CocoaPods to 1.6.0.beta.2
To work around https://github.com/CocoaPods/CocoaPods/issues/7708
The MIT license doesn't require that all files be prepended with this
licensing or copyright information. Realm confirmed that they're ok with this
change. This will enable some companies to contribute to SwiftLint and the
date & authorship information will remain accessible via git source control.
JP SimardandGitHub
Fumito NakazawaandGitHub
Frederick Pietschmann
Paul TaykaloandPaul Taykalo
Maksym GrebenetsandJP Simard
Marcelo Fabri
Blaise Sarr