Deprecate SwiftLint

[SDGGiesbrecht]

It would be good for Workspace to have a higher standard when it comes to false positives than SwiftLint provides.

This will involve several steps:

• Custom Plug‐In Tasks #195: Implementing custom plug‐ins so SwiftLint can still be used by those who want it. ✓
• Refactor Proofreading to Use SwiftSyntax & SDGSwiftSource #196: Refactoring proofreading to use SwiftSyntax. ✓
• Re‐implementing the useful SwiftLint rules as native rules and dropping SwiftLint from the default plug‐in list. SwiftLint had to be dropped early due to issues between it and Swift 5. Many rules have no native equivalents.

[SDGGiesbrecht]

@Dschee, I noticed your recent comment over at the SwiftLint repository. The same sorts of things have been annoying me for some time, so I have long been planning on replacing SwiftLint. The groundwork for it has been already been laid over the past few months over in the SDGSwift package (in tandem with the groundwork for documentation generation).

I pinged you in case you would like to look into using and contributing to Workspace’s proofreading functionality. (I even moved these from my local to‐do list to GitHub issues, just so you could get an idea of the roadmap.)

I am travelling for the next month and will be too busy to do much actual coding. But I keep a sharp eye on issues, pull requests and the Swift forums, and always carve out time to answer questions and review contributions to my projects and their external dependencies within a day or two.

Und die deutsche Sprache ist hier auch herzlich Willkommen. (Oder auch Türkisch...)

[Jeehut]

@SDGGiesbrecht Thanks for inviting me here. I've had a cursory look over the project and while it looks interesting in parts I don't quite get the big picture. What is this project's goal? Or to be more specific: Which problems does this project try to solve? To me right now it reads like it tries to solve very different problems that are all over the place. For example, managing several different Swift projects (the tagline sounds like this) is a very different task from linting Swift code.

I'm potentially interested, but before I can commit myself to this project, I'd like to understand the goalset first. Cause currently I'm working on several interesting open source projects already, including an alternative to Carthage, a linter for non-code stuff, an overhaul of BartyCrouch, a screen router for iOS apps as well as threee iOS Apps (this, that and that). So, I can't promise I will have much time soon, but I could put it on my list for early next year and give feedback before that.

[SDGGiesbrecht]

@Dschee,

The point of the Workspace project is to reduce all the menial and repetitive package maintenance and validation tasks to a single double click.

Workspace came about when I first entered the open source arena. Each project I tried to contribute to required me to find and install a half dozen new tools and follow a whole bunch steps of bootstrapping, code regeneration and test setup. I wanted any project I open‐sourced to have dead simple instructions and an initial set‐up learning curve of basically zero:

“I just downloaded the project. Now what?” → Double‐click Refresh.
“I submitted a pull request and it got a red “X”. How do I check it again on my own computer?” → Double‐click Validate.

At first all it did was fetch and use external tools, but over time those have been replaced one by one by internal implementations for various reasons.

---

As far as the proofreading part, at first it just fetched, set‐up, configured, and ran SwiftLint, but at some point a native proofreader was added because rules were needed that could not be expressed as regular expressions for custom SwiftLint rules. So basically, the workspace proofread subcommand serves roughly the same purpose as SwiftLint itself, just with a handful of additional rules. It can be both used and developed without ever caring or learning about the other functionality Workspace offers.

I am not requesting that you invest any additional time or resources, only offering an alternate place to contribute if you feel your investments elsewhere are being ignored or wasted. In case it wasn’t clear, I don’t really expect you to work on the listed issues. You can just propose and submit rules, help build a plug‐in interface for custom rules, or stick to whatever aspects are most fascinating or useful to you. I only listed the issues so you would be aware of planned and pending changes while you explore the project and if you end up deciding to write some code.

Whatever your proofreading/linting needs, I am committed to making Workspace either capable, customizable, or extendable to meet them.

[SDGGiesbrecht]

So, I can't promise I will have much time soon, but I could put it on my list for early next year and give feedback before that.

No hurry. I don’t want to needlessly add to your to‐do list.

[Jeehut]

Thank you for the clarification, I will look into this project from time to time and give feedback if I feel like I need to. Maybe at some point next year we can collaborate to bring development around Swift, Xcode & iOS forward.

[jpsim]

😢 I'm sorry you feel this way about SwiftLint. I think SwiftLint's support for regular expressions was an important factor in attracting community contributions, it's also led to many rules relying on them too much, leading to false positives and longer than necessary rule processing time.

For what it's worth, I'm actively looking at ways to make it easy to write SwiftLint rules using SwiftSyntax, potentially reducing false positives. See realm/SwiftLint#2476 and realm/SwiftLint#2480 for early progress.

[SDGGiesbrecht]

@jpsim,

Yes, I am still watching SwiftLint and I did see your recent work. You personally will always be a hero of mine for starting Jazzy and SwiftLint back in the days before Swift was not even open source and everything required clever hacking and reverse engineering of Xcode. Your reviews and comments have always been the most valuable whenever you had the time to chime in. (And the fact that you tracked this all the way over here is another good example.) It is probably precisely because you are so good at what you do that now when you have to delegate more, the others have difficulty living up to the standard you had established. If there were 10 clones of you curating those projects with ten times the time on their hands, I would probably never have grown weary of their contribution process. (But don’t spread yourself too thin; you need just as much downtime as the rest of us!)

[SDGGiesbrecht]

SwiftLint needed to be dropped early due to interoperability issues with Swift 5. It is unfortunate that most of its rules have no replacement.

The new custom task feature will allow integration of SwiftLint as soon as it is compatible with Swift 5 without needing to wait for an update to Workspace.

[Jeehut]

@SDGGiesbrecht According to the discussion here, Swift 5 support might actually take a while. But feel free to step in by providing a PR that matches the expectations expressed in the issue linked.

[SDGGiesbrecht]

There are no build failures (building with the Swift 5 package manager: swift build --configuration release). Runtime issues were the problem. It might just be realm/SwiftLint#2703, which already has a proposed fix: realm/SwiftLint#2706.

The prospect of submitting a PR is not particularly inviting. There are 34 open pull requests right now. That means a lot of rebasing amongst competing PRs. realm/SwiftLint#2077 went a year before it received any answer. When you (who appear to be an external contributor?) stepped in to answer, you deferred to the project higher‐ups for confirmation. A month later, they still haven’t answered.

Another consideration is the discussion of a possible official tool, the question of its scope, and the uncertainty of what that means for other similar tools. I am deferring work related to style checking—no matter the tool: Workspace, SwiftLint, swift-format, or any other—until there is a clearer answer. It is simply impossible right now to tell the difference between time well invested on unique features and time wasted on something about to be replaced.