WIP - feat: Add support for SPM plugins

[jcesarmobile]

Remove CordovaLib from the template and instead add a local "empty" swift package, in which cordova-plugin-add will add the plugins as dependencies if they are swift package manager compatible.

Plugin example to test with: apache/cordova-plugin-device#196

Using this approach plugins that want to add Swift Package Manager dependencies will have to be converted to be Swift Package Manager compatible and add dependences as they would to a regular Swift Package instead of relying in a new tag in plugin.xml

[dpogue]

There's a bit of Xcode mangling the project file (stripping licence comments, removing quotes around __PROJECT_NAME__ and __PROJECT_ID__, etc.) that will probably need to be fixed by hand.

The idea of a SwiftPM subproject is a good one and will make the process of adding/removing plugins significantly easier than trying to deal with the Xcode project directly. That said, would it make sense for CordovaLib to be referenced directly from the Xcode project rather than through the SwiftPM library?

One worry is that we won't be able to ship with CordovaLib pointing at master, we'll need to update that to point at a tag (which is annoying because that needs to happen as part of creating the tag to which it will point)

[jcesarmobile]

Keeping CordovaLib was a good call as it allows plugins to not have a dependency to cordova-ios, I tried several things like using an environment variable for setting the cordova-ios versions to use based on the installed version, and worked when running the app from the CLI, but was not working if running from Xcode since the variable is unset when the node process stops.
A similar option was to set the version on the Package.swift on platfor/plugin add, but as you mentioned, the tag has to exists, which is a problem for dev versions.

Also tried using cordova-ios from node_modules directly and works fine for the CordovaPluginsSPM project, but for plugins it would require to add cordova-ios as a dev dependency on plugins and then adjusting paths once installed in an app since the path to cordova-ios would be different when used from an app and from the plugin directory itself.

While I would have loved using the local version so we have the privacy manifest linked and on plugins we could run xcodebuild command to see if the plugin code builds without adding it to an app, keeping CordovaLib is the easier and less conflicting option.

[dpogue]

hmmm, I'd been hoping that we would be able to reference CordovaLib using SwiftPM, but directly in the app's Xcode project rather than through the CordovaPluginsSPM project's Package.swift... but if I'm reading your comment correctly that still causes issues for plugins? 😞

[jcesarmobile]

I didn't try that, but still, it would be a complex thing to do since if you add it to the template, when the template is turned into an app the path to cordova-ios's Package.swift will be different, so should be adjusted in the xcodeproj file.

Could be possible by having a Package.swift inside CordovaLib folder so the path is always the same, but would require having two Package.swift slightly different from each other, which could cause confusion and bugs if somebody edits one but not the other.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 15.38462% with 11 lines in your changes are missing coverage. Please review.

Project coverage is 77.91%. Comparing base (df4b8a6) to head (29fbbff).
Report is 1 commits behind head on master.

Files	Patch %	Lines
lib/Api.js	15.38%	11 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1430      +/-   ##
==========================================
- Coverage   78.35%   77.91%   -0.45%     
==========================================
  Files          16       16              
  Lines        1825     1838      +13     
==========================================
+ Hits         1430     1432       +2     
- Misses        395      406      +11     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dpogue]

Looking at this PR again, and the one thing I don't really love is the "magic" behaviour based on the existence of a Package.swift file in the plugin folder. It feels safer to rely on an explicit declaration in the plugin.xml file.

We've already overloaded the <framework> tag to do a billion things, so adding this wouldn't be totally unreasonable. i.e.,

<framework src="Package.swift" type="spm" />

Alternatively, the lib-file tag exists on Android but you could maybe stretch the definition to encompass Swift packages.

Using source-file is an option, but feels like that goes back to "magic" behaviour based on file names.

[jcesarmobile]

The point of having a Package.swift file is to turn the plugin into a swift package itself.
Having the Package.swift file makes it possible to add other swift packages the plugin wants to use as dependencies the “swift package way”.

Adding the Package.swift file in a framework tag makes no sense, in any case we could totally ditch the Package.swift file from plugins and use the framework tag to declare SPM dependencies, and then read the tag and write the dependencies in the CordovaPluginsSPM/Package.swift file but the tag will fall short for all the possible options and will end up creating a new tag in a future release as we did for CocoaPods.
The CLI should also copy the plugin files to the CordovaPluginsSPM project instead of to the app as if the plugin relies in the dependency and the dependency is in CordovaPluginsSPM project the plugin files should be there.

[jcesarmobile]

Anyway, I’m closing the PR, it was painful enough to address the requested changes on the project.pbxproj file, now it has conflicts that will be impossible to fix