-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove CocoaPods #23958
base: christmas-feature-branch
Are you sure you want to change the base?
Remove CocoaPods #23958
Conversation
Generated by 🚫 Danger |
📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.
|
📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.
|
96e2bd8
to
1e62678
Compare
That's for the value `CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER`, but it's useless to set `$(inherited)` for a Yes or No value because removing the value from the target will automatically make Xcode read it from the project, achieving the same result.
Was giving errors in Yoga: > Double-quoted include "YGEnums.h" in framework header, expected angle-bracketed instead
It resulted in a build failure: > React.framework/Headers/RCTAppearance.h:16:60: > A function declaration without a prototype is deprecated in all versions of C
Strange that `pod deintegrate` did not remove it. Maybe it was some custom piece of setup...
We don't have pods anymore
We don't use Pods anymore
1e62678
to
b2e22a1
Compare
Hey, nice work. It's a historic moment 😃 I've updated the tests in the target branch. It should be green now. I don't think I should/can review the changes in infra, but you get 👍 |
end | ||
|
||
abstract_target 'Tools' do | ||
pod 'SwiftLint', swiftlint_version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does the SwiftLint version get pinned now? It doesn't appear to be in Gemfile. I'd probably suggest trying SwiftPM since this project is not itself a dependency, so it should be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does the SwiftLint version get pinned now?
The version is defined in .swiftlint.yml
:
Line 1 in 388dbb1
swiftlint_version: 0.54.0 |
As for installing the tool, I'm happy to have a go at setting it up via SwiftPM. I ignored the problem for the context of this PR because there was already a lot going on.
I was also keen to ask everyone in the team what they'd prefer to do for provisioning. @jkmassel and I discussed. in the past the idea of having Apps Infra recommend and maintain a golden path for integration (which was CocoaPods but now needs to be updated) but leave the teams the option to decide how to go about it. For example, some people/team in the past expressed the feeling that running the linter on every build was too much friction when just hammering code together and they'd rather get linter feedback in the PR via CI only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest removing swiftlint_version
from .swiftlint.yml
and pinning it using SwiftPM. It should solve both issues: installation and pinning. Wdyt?
Note: I never tried it. I usually use Gemfile for tools.
rather get linter feedback in the PR via CI only
I'm sorry, I don't believe anyone would've preferred this 😄
tar -xvf Frameworks/Gutenberg.tar.gz -C Frameworks/ -k | ||
mv -n Frameworks/Frameworks/*.xcframework Frameworks/ | ||
rm -rf Frameworks/Frameworks Frameworks/dummy.txt | ||
mkdir -p Frameworks/hermes.xcframework/ios-arm64/dSYMs Frameworks/hermes.xcframework/ios-arm64_x86_64-simulator/dSYMs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given gutenberg-mobile
should have an hopefully short time left in the project, I think this rudimental way to fetch it is acceptable.
Also, the version is not likely to change at all, which again makes me comfortable with simply hardcoding it there and duplicating it it in Fastlane.
#import "WPAuthenticator-Swift.h" | ||
#import <WordPressAuthenticator/WordPressAuthenticator-Swift.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The header above was necessary when the lib was distributed via CocoaPods, but now we can access the Xcode-generated one directly.
This is unrelated with the CP removal for Gutenberg, but I noticed it when grepping "CocoaPods".
@@ -50,6 +50,7 @@ let package = Package( | |||
.package(url: "https://github.com/Automattic/wordpress-rs", revision: "alpha-20241116"), | |||
.package(url: "https://github.com/wordpress-mobile/GutenbergKit", revision: "4476d597b271778d001a26c50d74e527b54ebfef"), | |||
.package(url: "https://github.com/Automattic/color-studio", branch: "trunk"), | |||
.package(url: "https://github.com/allenhumphreys/AztecEditor-iOS", branch: "ah/spm"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👋 @mokagio - do we want to point Aztec to a fork? If I understand correctly this will block us if we need to push out the rare Aztec fix. Or maybe there's a timeline to get back to the WP org repo shortly after this change?
This is a replay of #23951 but onto #23923, as discussed with @kean here. I copied the PR description below, but you might want to check the original PR, too, for the inline comments.
Notice the base is #23960, which addresses the build failures from #23923, so that we can verify that CI is green with only the CocoaPods changes. Refer to that PR for explanations for UI tests failures, too.
Picks up where #23750, but starting from scratch because of too many project file changes since then, and completes the migration away from CocoaPods as the mean of linking the Gutenberg XCFramework.
The sequence of changes is roughly:
xcframework
sApp.js
file from the XCFramework to the build products as ajsbundle
to use the new locationTheree things noteworthy:
CLANG_WARN_STRICT_PROTOTYPES
andCLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER
, because of build failures in the XCFramework imports. It doesn't seem ideal, but also we have increasingly less Objective-C so it should be acceptable. Open to suggestions.make dependencies
before building the app. It felt a build phase was a bit too much, but it also feels like a line in theREADME
to call attention to this is not enough. Open to suggestions.xcworkspace
in favor of using only thexcproject
, which makes sense given the workspace was required by the CocoaPods setup which is now gone. I decided not to remove the workspace in this PR just to not add to an already big diff. Also, when I opened the standalone project file, some things weren't working out of the box, so I decide to postpone the move to it.SwiftLint
SwiftLint was previously fetched via CocoaPods and the automation was configured with that in mind. Removing CocoaPods also removes SwiftLint. In the interest of moving on with the removal process, I didn't provide an alternative setup for SwiftLint. The
rake lint
task merely prints a "no linter configured" message at the moment. As you can see in CI, this does not affect SwiftLint there, so we still have reliable checks in place.Testing
I published this from the Simulator: https://giotestdotsite.wordpress.com/2025/01/07/via-gutenbegkit-without-cocoapods/ (please ignore the slug, it's indeed mobile-gunteber) — Not sure if the HTML source can show it, but I did check locally that the experimental editor toggle was disabled. Besides, the UI being a bit different between the two helps being aware of it.
Apart from that, I'd say run the prototype build on device and see if the Gutenber-via-XCFramework editor works as expected.
Regression Notes
It's possible that some behavior in the Gutenber-XCFramework editor will be compromised. However, I don't see why, once the editor loads, all the code should be the same.
Had a go at publishing a post from the Simulator.
N.A.
PR submission checklist:
RELEASE-NOTES.txt
if necessary. - N.A.Testing checklist: