Replies: 3 comments 3 replies
|
I've pinged internal team about this |
|
and I always thought React Native (cc @cipolleschi) was bigger consumer of Xcodeproj, but maybe they've removed a chunk of that dependency. |
|
You are probably right there, but they're not rubyists 👍🏻 |
|
Over next week or two I'm going to peek around the codebase to see what kind of scale this is. Been a consumer of the package for years, but honestly unaware of the scale of the maintenance. In my first peek I saw XcodeProj depends on Claide and Nanaimo which are also Cocoapods packages, then some of those packages use even more XcodeProj projects like Cork. Basically trying to understand the scale of what is a 3rd party vs 1st party dependency & what might be maintained going forward and what might be in the bucket of this. Tossed you a PR in the meantime to fix up the CI/CD on the main repo - CocoaPods/Xcodeproj#1034 |
|
I'd argue that Nanimo is kinda the only essential dependency in that list, no idea if folks use the cli which comes with Xcodeproj but I think you could safely argue that dropping the CLI and reducing deps is a solid 2.0 strategy to make it maintainable |
|
So this is what we are thinking of. We are probably not in the best position ourselves to march it forward with breaking changes, v2, etc without a longer period of ownership under our belt. However, we still heavily depend on it so we are probably best group to "keep it alive" in the stance that it continues to work with the Xcode adjustments on horizon. We know React Native is in the middle of a journey to reduce more of their dependency on it with their new Node based solution - https://github.com/react/react-native/tree/main/packages/react-native/scripts/swiftpm, so probably can't count on them to support it more heavily. So we could look into a flow of:
Open to jumping on a call if you want to talk it out. |
Uh oh!
There was an error while loading. Please reload this page.
Hey folks, we've not really been making (/accepting/deploying) Xcodeproj changes over the the CocoaPods side - as you folks are probably the biggest consumers of the library, do you have an interest in taking over the dependency?
IMO as you already have a monorepo setup I think it'd be reasonable to migrate it over to this repo and I can archive the cocoapods repo (with a README update) and help pass the rubygem access over when you're ready
All reactions