Remove explicit macOS platform requirement from Package.swift

[mokagio]

It was there because of an error related to the WordPressShared dependency using the SwiftLint build plugin. I discovered what I think is a better approach to set up the dependency, which does not require explicitly declaring macOS support.

Before

After

Testing Details

See green CI.

However, notice CI doesn't build the package, so the test might give a false positive for this change.

One way to verify it is to run the following script:

#!/bin/bash

# Quit Xcode in case there is a version of WordPressKit open that could give us trouble
osascript -e 'tell application "Xcode" to quit'

mkdir -p xcode_staging
mv ./WordPressKit.xcodeproj xcode_staging
mv ./WordPressKit.xcworkspace xcode_staging

bundle install

# The device parameter is required (when running standalone?) or the underlying xcodebuild call will fail with:
# Building a Swift package requires that a destination is provided using the "-destination" option. [...]
bundle exec fastlane run run_tests \
  package_path:. \
  scheme:WordPressKit-Package \
  device:'iPhone 15 Pro'

mv xcode_staging/* .

rm -rf xcode_staging

---

• Please check here if your pull request includes additional test coverage. — N.A.
• I have considered if this change warrants release notes and have added them to the appropriate section in the CHANGELOG.md if necessary. — N.A.

[dangermattic]

	1 Warning
⚠️	Package.swift was changed without updating its corresponding Package.resolved. Please resolve the Swift packages in Xcode.

Generated by 🚫 Danger

[iangmaia]

@mokagio about the @dangermattic warning below, I guess it does make sense on this case? Or there was no change in the Package.resolved?

1 Warning
⚠️ Package.swift was changed without updating its corresponding Package.resolved. Please resolve the Swift packages in Xcode.
Generated by 🚫 Danger

[mokagio]

@iangmaia good observation, thanks.

Package.swift changed, so Danger did it's job posting the warning. However, the warning's wording is misleading because the kind of change we had here does not affect the Package.resolved content.

I think the wording is an adaptation of what we used for Podfile and Podfile.lock. The difference is that in CocoaPods every change to Podfile results to a Podfile.lock change because the lockfile contains a hash of the Podfile. But SPM does not do that.

Maybe we should update the wording... 🤔

⚠️ Package.swift was changed but its corresponding Package.resolved was not. Please ensure Package.resolved is up to date if any of the dependencies in Package.swift changed.

Alternatively, we could improve the logic that picks up the Package.swift changes. But that might prove tricky given that's a Swift file which can contain code etc. I remember @crazytonyli wrote some SourceKit code to compute certain changes, so maybe it could be done. But... I wonder about the ROI of going down this particular rabbit hole.

[iangmaia]

However, the warning's wording is misleading because the kind of change we had here does not affect the Package.resolved content.

That's what I was unsure about, though I was imagining Package.resolved changes would be needed.

Maybe we should update the wording... 🤔

⚠️ Package.swift was changed but its corresponding Package.resolved was not. Please ensure Package.resolved is up to date if any of the dependencies in Package.swift changed.

That's better indeed!

Alternatively, we could improve the logic that picks up the Package.swift changes. [...] I wonder about the ROI of going down this particular rabbit hole.

Indeed! I think an improved message already helps a bit. I've then created the issue Automattic/dangermattic#65