Build-time linting

[steeve]

Hi,

rules_go has this concept of build-time code analysis.

It is very very useful in a team context and has saved us many times. It's nicer than running it via CI.

Opening this issue to that the idea lives somewhere, it would be killer for rules_swift to have a feature like that.

Thanks!

[keith]

Which specific linters do you think would be worth doing here? Also I guess this is an interesting trade off between build performance and correctness. My personal opinion is that Swift is "strict enough" that I'm not sure I can think of an existing linter I would want to run as part of my iteration cycle, where my outside perspective of golang is that there are many foot-gun situations that it makes sense for.

[steeve]

I was thinking for something like https://github.com/realm/SwiftLint, not only gotchas, but team style for instance.

[jgavris]

We have a few custom Swiftlint rules, and a lot of Swift files...being able to define them in a filegroup and also include the build rule to skip cached runs would be a 5-10 second cut off the top of some builds. Could probably cleverly use a sh_test rule though.

[keith]

FWIW for a current solution for this I think you could define your own swiftlint rule that takes some swift files as inputs, and outputs an empty swift file, and then add that empty swift file as a dependency of your swift_library target, then when you build your library it will first have to run swiftlint to produce that file, and then any changes to your actual files should also affect the inputs of the swiftlint rule to trigger a re-run

[tinder-maxwellelliott]

We use https://github.com/apple/apple_rules_lint as a frontend to our SwiftLint invocations, it's worked very well but is kinda slow when run via Bazel in an Xcode prebuild phase

[keith]

For a pre-build phase we just run a shell script that queries git for changed files and runs swiftlint via bazel, which I think might be a bit nicer than treating them as a few test targets