breautek commented on PR #1515: URL: https://github.com/apache/cordova-ios/pull/1515#issuecomment-2551810276
> Even with the plan to rewrite, it's not clear (for our own Apache plugins) if we can point them at the master branch of cordova-ios and still pass a release vote, because they would be pointing to a dependency that has not had a release vote. This could result in needing to churn the version dependency in every plugin every time we release a new cordova-ios version (even if we don't need to publish those changes). I would think it's not acceptable to point it to master branch as that would effectively be using the dev build. At minimum it would need to be using the `rel/<version>` tag. But we could potentially have a "Local" SPM package that is just simply shipped with the cordova-ios tarball. The app template could reference it locally via file path. Not 100% sure how that will work with plugins however. > Each Swift package is treated as its own self-contained library, with access only to the dependencies that it declares. This means that plugins cannot access CordovaLib headers unless the declare a dependency on CordovaLib in their own Package.swift file. I think this is more of a side issue because our plugins are not proper modules. They are just loose source code that eventually makes their way part of the App project. And I assume SPM packages are importing these packages as their own build targets, which means they have their own build configurations (and thus needs a reference to the CordovaLib framework). This in itself shouldn't be a blocker though, as long as `CordovaLib` framework is consumed as a dynamic library, instead of a static library. Plugins should be able to declare the dependency on CordovaLib and compile against it without providing the CordovaLib framework itself. The application project will be the one responsible of importing the `CordovaLib` framework, and making sure that the dynamic library is available during runtime (by packaging it with it's product). Because most plugins are not pre-compiled, if they are any incompatibilities, it should appear during build time. Plugin authors pre-building their plugins and distributing a prebuilt binary however would need to take extra care to not call on an API that might not exist without properly guarding so, as it would cause runtime crashes. > I think this is more of a side issue because our plugins are not proper modules. Extending on this, a year or two ago I was experimenting with an alternate approach in authoring plugins, so that plugins can have their own native projects and can compile (and potentially run) independently of a Cordova project. Would be very useful to have for using native unit test features. This involved having plugins be in their own projects and having their own build targets, so each plugin would produce their own `.framework` which gets imported by the Cordova application. This mostly worked but I did run into runtime errors where the cordova framework failed to look up any symbol that came from a dynamic library, wihch the cordova framework does when processing native bridge calls [here](https://github.com/apache/cordova-ios/blob/3737f515ba0b30ac8e32595a9ab9626e7ae9401d/CordovaLib/Classes/Public/CDVCommandQueue.m#L184-L193) if my memory serves me right. Just some thoughts. I've been experimenting with SPM with my own framework, and will be sharing what worked for me once I have something but it is a very different architecture than Cordova. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
