Closed TylerBreau closed 1 year ago
Merging #1266 (9b0dc61) into master (ad60924) will increase coverage by
0.02%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## master #1266 +/- ##
==========================================
+ Coverage 78.25% 78.27% +0.02%
==========================================
Files 15 15
Lines 1761 1763 +2
==========================================
+ Hits 1378 1380 +2
Misses 383 383
Impacted Files | Coverage Δ | |
---|---|---|
lib/plugman/pluginHandlers.js | 90.15% <100.00%> (+0.10%) |
:arrow_up: |
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more
EDIT: cordova-common, cordova-lib, and cordova-cli has been closed in favour of https://github.com/apache/cordova-common/pull/181.
original comment: This change spans across 5 repositories. These are the 5 PRs:
Nice, thank you.
Nice, thank you.
Your welcome. BTW, this PR is still in draft mode as cordova-common, cordova-lib, and cordova-cli PRs will likely become obselete as a result of https://github.com/apache/cordova-common/pull/181.
Opening PR for review.
Noting again, this PR requires a cordova-cli that is using cordova-common@4.1.0. If your environment does not contain this, cordova-ios will not receive the link attribute in an actual cordova project. Unit tests will work regardless because they use cordova-common directly.
Forced-push to update branch with master.
The failing test does not appear to be related to this PR.
We've investigated and determined that issue happens in current master on NodeJS 18. I've created a bug ticket with further details: https://github.com/apache/cordova-ios/issues/1290
Waiting on https://github.com/apache/cordova-ios/pull/1302 so that we can confirm if all test passes.
Update is backwards compatible with previous embed behaviour.
Platforms affected
iOS
Motivation and Context
Currently, the framework tag does not support both linking and embedding a framework. Comments in the code suggest this was a limitation in Apple's code.
This limitation no longer exists. The current default behaviour of XCode (version 14) when dragging and dropping an XCFramework into General -> "Frameworks, Libraries, and Embedded Content" is to both embed and link the XCFramework. I have only tested this with XCFramework but I assume other kinds of frameworks are the same.
This change allows the framework tag to both link and embed a framework.
In my real-world use case, I am using custom XCFrameworks to get c binaries into my cordova app. If the XCFramework is not embedded then the App will crash during runtime because it can not find the binaries. This is expected because the binaries were not embedded into the app. If the XCFramework is not linked then the App can not be built due to linker errors. This is expected because the binaries are not being linked to the app.
cordova-ios unit tests use cordova-common directly. As a result, this PR depends on https://github.com/apache/cordova-common/pull/181 (cordova-common 4.1.0). In actual usage, cordova-cli parses the framework attributes and gives them to cordova-ios. As a result, this PR also depends on a cordova-cli that is using https://github.com/apache/cordova-common/pull/181 (cordova-common 4.1.0)
cordova-docs pr: https://github.com/apache/cordova-docs/pull/1267
Description
Add code that checks for new framework attribute "link". If link is not explicitly set, fallback to the previous behaviour (link = !embed).
Testing
I've ran npm test.
Tested various combinations of framework tag's embed and link attributes by installing a plugin using these attributes. I would observe how the XCFramework is added to the the XCode project with the following focuses: -Is the XCFramework embedded (or not embedded) in Build Phrases? -Is the XCFramework linked (or not linked) in Build Phrases? -Is the XCFramework set to "Embed and Sign" in General?
I have ran my company's app using these changes.
Checklist
(platform)
if this change only applies to one platform (e.g.(android)
)