Make SwiftLint available as a build tool plugin

[technocidal]

Motivation

SwiftLint is an important part as a build phase for many projects. Depending on where the project is being build the path where swiftlint is located on a machine can differ. One example is the recent Homebrew path change when Apple introduced Apple Silicon machines. Using SwiftLint as a plugin means that there is no need for an external package manager to install it, less setup during initial project setup and a more portable project overall.

Open Questions

• Do I need to add additional parameters to the actual swiftlint call?

[SwiftLintBot]

	1 Message
📖	Skipping OSSCheck because SwiftLint hasn't changed compared to 'main'

Generated by 🚫 Danger

[tboogh]

Great initiative, a suggestion is that the plugin should look for a configuration file in the project path such as the SwiftGenPlugin does https://github.com/SwiftGen/SwiftGenPlugin/blob/stable/Plugins/SwiftGenPlugin/Plugin.swift

[jpsim]

Thanks for the PR! Does the SwiftPM plugin interface allow for any user configuration, like having users specify the path to the config file? If so, supporting that could be nice.

By default, SwiftLint will look at the root of the project for a .swiftlint.yml file and will traverse the directory tree to look for child configurations.

If we add this, there should also be a section in the readme that explains how to configure it for people's projects.

[technocidal]

@tboogh @jpsim

Thanks for your feedback!

I'll research the configuration options and will include some version of the configuration file discovery similar to SwiftGen.

Anything in particular I'll need to keep in mind regarding the Readme?

[jpsim]

Anything in particular I'll need to keep in mind regarding the Readme?

Basic instructions for how to get it up and running in projects would be helpful. Via Package.swift and Xcode ideally, since I suspect those setup processes to differ a bit.

[technocidal]

Great initiative, a suggestion is that the plugin should look for a configuration file in the project path such as the SwiftGenPlugin does https://github.com/SwiftGen/SwiftGenPlugin/blob/stable/Plugins/SwiftGenPlugin/Plugin.swift

@tboogh

There is a small difference between SwiftGen and our implementation. SwiftGen only supports Swift packages while I'd like to support SwiftLint as a Xcode Build Tool Plugin. There are some slight differences in the API.

SwiftLint has it's own child configuration discovery which means that we probably don't need to look for any configuration if we find a .swiftlint.yml at the project root. The API for Xcode plugins only gives you the target which includes a list of files assigned to this target. SwiftLint configuration files are generally not assigned to a target so they don't show up here. Targets are also not required to have their own root directory like Swift packages. That makes a little tricky to figure out where to look for a potential configuration.

[technocidal]

Regarding the whole configuration thing: I can't find an obvious way to pass in the path to a configuration file.

This means that we can either add this in this pretty barebones state and explain it really well or wait until the situation improves.

[jpsim]

Where does this resolve to? Somewhere semi-private where we can write our cache data to without bothering the user? I assume this is necessary for sandboxing reasons and we're not allowed to write to caches directory here?

[technocidal]

Yes. This is a temporary directory inside Derived Data.

From the Swift Package Manager documentation/proposal:

/// The path of a writable directory into which the plugin or the build
/// commands it constructs can write anything it wants. This could include
/// any generated source files that should be processed further, and it
/// could include any caches used by the build tool or the plugin itself.
/// The plugin is in complete control of what is written under this di-
/// rectory, and the contents are preserved between builds.
///
/// A plugin would usually create a separate subdirectory of this directory
/// for each command it creates, and the command would be configured to
/// write its outputs to that directory. The plugin may also create other
/// directories for cache files and other file system content that either
/// it or the command will need.
public let pluginWorkDirectory: PackagePlugin.Path

The initial proposal also includes that explanation as well as hints to future improvements regarding user-defined options for plugins.

[jpsim]

Regarding the whole configuration thing: I can't find an obvious way to pass in the path to a configuration file.

Fair enough, SwiftPM/Xcode must not expose any way to configure the build tool, it just has to work by default, which I think in the common case should work fine for SwiftLint. Maybe extensibility will come in the future...

[technocidal]

I feel a little bit bad about this but I'm not confident that the Xcode Plugin integration is ready. I'm unable to get the plug-in to run consistently with my work project which I used as a test bed. There are a couple of issues:

• Adding and subsequently removing the plug-in from the project results in Xcode still trying to run the plug-in even though it's no longer configured as a build phase. Only a very thorough clean (clearing Derived Data etc.) gets rid of that issue. I'll report this as a radar and will post the link here as well.

• The plug-in seems to work fine when SwiftLint reports errors but throws a very weird error when only warnings are reported. Something about non-zero exit Code during execution. This is particularly weird as the linting up until that point runs smoothly and reports the appropriate warnings.

Using it as a plug-in for a Swift Package seems to work a lot better so I'll keep that integration around. I'll push these changes later today.

If anyone wants to take a look, feel free! I'm at my wits end to be honest.

[polpielladev]

I feel a little bit bad about this but I'm not confident that the Xcode Plugin integration is ready. I'm unable to get the plug-in to run consistently with my work project which I used as a test bed. There are a couple of issues:

• Adding and subsequently removing the plug-in from the project results in Xcode still trying to run the plug-in even though it's no longer configured as a build phase. Only a very thorough clean (clearing Derived Data etc.) gets rid of that issue. I'll report this as a radar and will post the link here as well.
• The plug-in seems to work fine when SwiftLint reports errors but throws a very weird error when only warnings are reported. Something about non-zero exit Code during execution. This is particularly weird as the linting up until that point runs smoothly and reports the appropriate warnings.

Using it as a plug-in for a Swift Package seems to work a lot better so I'll keep that integration around. I'll push these changes later today.

If anyone wants to take a look, feel free! I'm at my wits end to be honest.

Hey @technocidal, we have been able to implement a plugin at work that works quite well for us. It ships with our default .swiftlint.yml (which obviously works in our case but wouldn't be desirable in this case) and is configurable.

On top of that, we scan the target's root directory for a .swiftlint.yml as just running the executable didn't pick up the config file, we had to explicitly declare it. For Xcode targets it's a bit different as we've had to make sure we include .swiftlint.yml as a file reference to the Xcode target.

To make our plugin work we had to pass the --in-process-sourcekit flag that I can't see on this PR, maybe something worth considering? This picks the source kit version that runs in process to comply with the plugin's sandboxing rules.

[polpielladev]

Also, I am happy to share code (or even add a commit) for how we do the configuration discovery, albeit not very ideal for Xcode projects. It could potentially just be added to the package version for now?

Also, great work on this! I'm so excited to see more and more plugins making it into open source projects 🚀 🎉

[jcabreram]

@pol-piella Can you please share the code? I'm sure it'll be useful for a lot of us wanting to add SwiftLint as a plugin to our projects. Thanks!

[jcabreram]

It'd be nice to add the example of how to add it as a package dependency for the people who don't know (the version number can be updated once this is released):

    dependencies: [
        .package(
            url: "https://github.com/realm/SwiftLint",
            from: "0.49.1"),
    ]

[weakfl]

Not sure what you need @jcabreram, but I'm using SwiftLint as Xcode plugin, see here.

[polpielladev]

@pol-piella Can you please share the code? I'm sure it'll be useful for a lot of us wanting to add SwiftLint as a plugin to our projects. Thanks!

I think the main change that made it work for us was passing the --in-process-sourcekit to the executable. It's a shame I can't commit to this PR, but could try open a new one adding this flag and link it here?

[polpielladev]

@technocidal @jpsim I have opened a new PR (as I can't push to this one) #4259 preserving all the changes the @technocidal has made and just adding the extra flag that makes Sourcekit run in-process. We have been using this config at work with no issues so far. Also happy to look at any test/CI failures that come up and get this ready to be merged if people are happy with it 🎉

[technocidal]

@pol-piella Your PR looks great and thank you for taking this feature over the finish line 🎉

[polpielladev]

@jpsim I have fixed the CI issues and merge conflicts with the PR now #4259 . Are we happy to merge the changes that @technocidal made and my flag addition? Happy to make any more changes if required 👍

[jcabreram]

@jpsim You seem to have closed #4259 due to --in-process-sourcekit being deprecated. Any suggestion for moving this forward?

[jpsim]

@jpsim You seem to have closed #4259 due to --in-process-sourcekit being deprecated. Any suggestion for moving this forward?

Is this PR still the one you all want to propose to merge? We shouldn't use --in-process-sourcekit because it's deprecated and done nothing. SourceKit is always run in-process now.

There are failing CI jobs here, but I think they were infrastructure errors? I'm re-running the failed jobs now.

[jpsim]

Merged in 3fd1573. Thanks for your contributions and patience everyone!

[tboogh]

Thanks for taking the time to look into it. In my opinion a basic implementation now is way better than a more advanced one in the future. Xcode will probably evolve the build plugin support over time and perhaps yield a solution for configuration that makes sense for SwiftLint.On 15 Sep 2022, at 20:42, Johannes Ebeling ***@***.***> wrote: Regarding the whole configuration thing: I can't find an obvious way to pass in the path to a configuration file. This means that we can either add this in this pretty barebones state and explain it really well or wait until the situation improves. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[tonyarnold]

Hi folks, before I open an issue: I'm struggling to get the build plugin to find/resolve my .swiftlint.yml - it's ignoring the ones that are in my project root and local package root.

Is there a trick to this?