Skip to content
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

Improve flow installing CocoaPods #1819

Closed
szymonrybczak opened this issue Feb 6, 2023 · 9 comments
Closed

Improve flow installing CocoaPods #1819

szymonrybczak opened this issue Feb 6, 2023 · 9 comments
Labels
feature request no-stale-bot This issue cannot be marked as stale by stale bot

Comments

@szymonrybczak
Copy link
Collaborator

Describe the Feature

While creating a new project with react-native init, we're automatically installing pods, (and sometimes it can cause errors, and non-advanced users creates issues that init command doesn't work, which isn't actually true),

Solution

We want to move part with installing pods to moment, when user runs app part via (run-ios / build-ios / or by pressing "Play" button in Xcode), then we'll check if user installed pods or not. If not we'll prompt user to install pods.

Also we would like to check if dependencies changed in package.json, if yes - we'll prompt user to run pod install, before starting the build.

@cipolleschi
Copy link
Contributor

Hi there!
I think the intent is good but it will be tricky.

Doing that on npx react-native run-ios, npx react-native build-ios or even yarn ios could be feasible as we just have to add an extra command before the current flow to actually install the pods.

Doing that from Xcode is not possible.
Cocoapods generates a Workspace: a container for the user project and the pod project.
After Cocoapods completes, users never have to use the xcodeproj anymore: they must use the xcworkspace.

Installing pods when pressing Play would be confusing as we would have to:

  • install the pods
  • kill Xcode
  • open the xcworkspace generated

Seeing the Xcode window getting close could push the users to think that something went wrong or that the play button make Xcode crash, so I'd avoid that.

Also we would like to check if dependencies changed in package.json, if yes - we'll prompt user to run pod install, before starting the build.

Can't we run pod install as part of yarn add XXX?

@tido64
Copy link
Contributor

tido64 commented Feb 6, 2023

+1 on everything @cipolleschi said above. You could move pod install to build-ios or run-ios, but beware that running pod install even when there has been no changes is quite expensive. Especially for bigger projects, this can add minutes.

Also we would like to check if dependencies changed in package.json, if yes - we'll prompt user to run pod install, before starting the build.

I would not depend on package.json for changes. Lock files (e.g. package-lock.json, yarn.lock) are more reliable. Versions can change without touching package.json. I would also avoid running pod install as part of any other commands for the same reason as above, and also because a number of package managers don't support adding arbitrary lifecycle scripts. Would it be enough to ask the user to re-run pod install if we detect potential changes during build-ios or run-ios?

@satya164
Copy link
Member

satya164 commented Feb 7, 2023

You could move pod install to build-ios or run-ios, but beware that running pod install even when there has been no changes is quite expensive.

This has to be conditional (e.g. CLI stores some metadata and only runs pod install when that metadata changes). expo-cli does something like this already, though not sure what logic they use to detect changes.

There could be a config option/parameter to skip installing pods for projects that never want to install pods automatically.

Would it be enough to ask the user to re-run pod install if we detect potential changes during build-ios or run-ios

One option could be to prompt in interactive mode if the user wants to install pods (with a timeout in case they switch to another app) if CLI detects any changes.

@pawelkata
Copy link
Contributor

I did a small research on the topic and as it turns out the Expo basically checks for Pods folder in the project and the lockfile and if any is not present then it installs pods. It also caches hashes of dependencies and devDependencies from podfile.json and checks against them.

We could implement this similarily on our end however I'm not sure if moving pod installation from init to build-ios/run-ios is an optimal idea, because since it rarely changes after initial setup it would be redundant to try and install them on each subsequent run/build (esp. if there are more robustly configured Podfiles).

It might simply be more efficient to just check for changes and let the user know if there were any or ask interactively. We could cache hashes of dependencies, devDependencies and the podfile hash.

A param for skipping pod installation during init, otoh, might be a good idea.

WDYT?

CC: @satya164 @szymonrybczak

@cipolleschi
Copy link
Contributor

On a second thought, I'm not sure that it is good, not to install pods at init.

If we don't do that, users can't open the project in Xcode (as there is no properly configured xcworkspace) and they have to run pod install manually... which can open a whole new can of worms.

WDYT?

@cipolleschi
Copy link
Contributor

A param for skipping pod installation during init, otoh, might be a good idea.

We already have that param! :D

you can run npx react-native init <AppName> --skip-install. This will skip both yarn install and pod install, so you should run yarn install afterward.

@satya164
Copy link
Member

On a second thought, I'm not sure that it is good, not to install pods at init.

If we don't do that, users can't open the project in Xcode (as there is no properly configured xcworkspace) and they have to run pod install manually... which can open a whole new can of worms.

WDYT?

Yeah I feel that automatically running pods when needed is useful, but don't see any advantage of not running on init. If we have some change detection then it'll be skipped during the build anyway if it was run during init.

@github-actions
Copy link

There hasn't been any activity on this issue in the past 3 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days.

@github-actions github-actions bot added the stale label May 12, 2023
@szymonrybczak szymonrybczak added no-stale-bot This issue cannot be marked as stale by stale bot and removed stale labels May 15, 2023
@szymonrybczak
Copy link
Collaborator Author

I'm closing this issue, as it was implemented in #2077 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request no-stale-bot This issue cannot be marked as stale by stale bot
Projects
None yet
Development

No branches or pull requests

5 participants