Xcode cannot resolve package dependencies for Swift Package project with version 0.50.0

[engineeric]

New Issue Checklist

• Updated SwiftLint to the latest version
• I searched for existing GitHub issues

Describe the bug

When trying to use SwiftLint 0.50.0 in a Swift Package project, Xcode 14.1 fails to resolve dependencies because SwiftLint is dependent on an unstable version of SwiftSyntax.

Environment

• SwiftLint version 0.50.0
• Xcode 14.1
• Swift Package Manager

.package(url: "https://github.com/realm/SwiftLint.git", from: "0.50.0")

Error: "Failed to resolve dependencies Dependencies could not be resolved because root depends on 'swiftlint' 0.50.0..<1.0.0.
'swiftlint' >= 0.50.0 cannot be used because no versions of 'swiftlint' match the requirement 0.50.1..<1.0.0 and package 'swiftlint' is required using a stable-version but 'swiftlint' depends on an unstable-version package 'swift-syntax'."

[jpsim]

How is it unstable when it’s pinned to a specific commit?

[engineeric]

Apple shenanigans 🤷

[jpsim]

I was able to cut a tagged release for SourceKitten and am updating that here: #4569

However, I'm still trying to find a good way to solve this for SwiftSyntax. I think I'll need to depend on tags rather than commits. Tags are published fairly regularly and I think SwiftPM would be satisfied with the "stability" of tags over commits: https://github.com/apple/swift-syntax/tags

[jpsim]

I think you can work around this by pinning to an exact version of SwiftLint:

.package(url: "https://github.com/realm/SwiftLint.git", revision: "0.50.0"),

So instead of from: use revision:.

[designatednerd]

How is it unstable when it’s pinned to a specific commit?

I also was not expecting "But I literally pointed at one specific commit how the hell is that unstable", but it appears in SPM's definition, it is. I can't remember if it just has to be a published tag or if it also has to be a semver compliant tag, but it's at least got to be a tag.

[jpsim]

I'm going to close this issue, and won't switch to swift-syntax tags unless there's a reason someone can't use revision: for some reason.

[designatednerd]

@jpsim FWIW: I can't use revision because I'm using it on several internal libraries, which then means anything that imports those libraries has to use revision, because it then has a dependency on SwiftLint, which is unstable.

This also goes for any OSS lib that wants to use SwiftLint via SPM. I don't think leaving it at "just point to a specific revision" is going to be a long term workable solution.

LMK if I can help twist some arms to get a release cut somewhere.

[jpsim]

Ok, thanks for sharing that. Another way we could do this is to use the binary releases of SwiftLint but then that might mean not supporting Linux. But then the plugin would have no dependencies (in the SwiftPM sense of the term).

[andyj-at-aspin]

As with the original poster, I have SwiftLint referenced by a sub-package in my projects just so a build script can do a command-line swift build of it before running a lint over the entire project. This is so my CI/CD servers always get the required version of SwiftLint and report all warnings during analysis actions without needing user intervention to go and ensure the CI/CD server has the necessary version of SwiftLint already installed on it.

As the package file exists in my project workspaces, Xcode detects it and adds it to the workspace's Package.resolved. Because SwiftLint is now using a non-Tag reference to SwiftSyntax it's considered unstable by Xcode, making my complete Package.resolved unstable and preventing projects from building for release. I am now faced with either removing SwiftLint from my project workflows entirely, sticking at the last version considered stable by SPM - 0.49.1 or losing all automation and having to obtain and update SwiftLint on all development and CI/CD hardware manually.

I'd be really grateful if some way around this was found. As far as the SwiftSyntax folk seem concerned you've been tracking their pre-release bleeding edge for a while, going by the frequency of alterations to SwiftLint's Package.swift - but then maybe you managed to automate that.

[jpsim]

Possibly one way to work around this would be for me to fork SwiftSyntax and cut semver release tags there.

I really dislike the lack of flexibility of SwiftPM at the moment.