Repository navigation
[0.73] react-native.config.js is displayed in the upgrade helper #2202
Description
Description
I was upgrading my app from 72 to 73 and reviewing the Upgrade Helper changes, and I saw a new file react-native.config.js:
I looked in the react-native repo, but this file isn't in the template. So I looked in the CLI and found the change that includes this comment:
/*
Starting from 0.73, react-native.config.js is created by CLI during the init process.
It contains automaticPodsInstallation flag set to true by default.
This flag is used by CLI to determine whether to install CocoaPods dependencies when running ios commands or not.
It's created by CLI rather than being a part of a template to avoid displaying this file in the Upgrade Helper,
as it might bring confusion for existing projects where this change might not be applicable.
For more details, see https://github.com/react-native-community/cli/blob/main/docs/projects.md#projectiosautomaticpodsinstallation
*/So the intention was to not check-in the file to the template, so the helper didn't include it. But for some reason, the helper does include it.
Activity
rickhanlonii commentedon Dec 11, 2023
Personally, I feel like when I run the init command, I should be able to see all of the same files created in the react-native template repo. And since this is already there, I would probably just check it in.
rickhanlonii commentedon Dec 11, 2023
The default value of this option is true, right? Why create the file at all then? Why not include instructions for setting it to false if you don't want the behavior, no file needed?
TMisiukiewicz commentedon Dec 12, 2023
@rickhanlonii indeed it shouldn't be displayed in the upgrade helper. Initially our idea was to support automatic pods installation without any additional setup, however we decided to hide this feature behind this flag and enable it by default only for freshly started projects. For all the projects upgrading to newest version this should be optional, as there might be various reasons where this workflow would not fit:
pod installis expensive and might take a lot of time on complex projects. Those kind of projects very often have Pods directory checked into source control sopod installis not desiredFor those reasons, we wanted to run
pod installwhen using ios-specific commands by default only for projects started withinitfrom version 0.73. It runs automatically if pods are not installed, or there is a new native dependency discovered in config, so user don't have to remember about installing pods manually. A warning that it might not work properly when upgrading RN is in the docs. This workflow also speeds up theinitprocess, where pods installation is optional now.I already checked Upgrade Helper but couldn't find anything that prevents from showing specific files. Maybe it can be done in
rn-diff-purge? Would love to get in touch with someone maintaining it to find the proper solution. An alternative solution is adding a comment in the file itself, indicating that it is created by the CLI and it's optional when upgrading to newer RN version, however I'd prefer that file to not be displayed at all.TMisiukiewicz commentedon Dec 12, 2023
One more solution that comes to my mind is creating this file only if
process.env.CIisfalse, I assumediff-purgeis running a job to generate a fresh project for each version. I assumeinitis not a command that is ran on CIs heavily, it should not break anything for those who do that.cortinico commentedon Dec 12, 2023
I second @rickhanlonii thoughts as we should strive to don't manipulate the template in the
initcommand.Can we do the following changes instead:
automaticPodsInstallation == truefor everyone in 0.73 (both newly created and upgrade projects)react-native.config.jsfile generation in theinitcommandbuild-ios/run-iosthat is triggeringpod installby saying:TMisiukiewicz commentedon Dec 12, 2023
@tido64 what are your thoughts about it? I remember we discussed that when it was initially introduced
tido64 commentedon Dec 12, 2023
The current implementation is flawed and will break all existing setups internally at Microsoft. There is no way you can ship this as opt-out in its current shape. For transparency, here's the list of issues I posted:
bundle exec pod install, which assumes that users installed CocoaPods via RubyGems. This may not always be the case — you can also install it with Homebrew or MacPorts. CI services may be even more creative.Gemfiledoes not include CocoaPods. Ruby will throw an exception if that's the case, failingrun-ios. This is the original issue I reported in the 0.73 roadmap discussion.Podfile.lockandPods/Manifest.lock. This means that it won't pick up changes that are done outsidepackage.json. For instance, if someone updatedyarn.lockonly.pod installis prohibitively expensive on larger projects. We have apps where this can take 30 minutes or more. It's so slow, they check in thePodsfolder so that devs don't have to run it unless they're updating dependencies. With this version, if you pull down the latest changes and there have been dependency updates, CLI will unnecessarily runpod install. This is a big no for us.Podsfolder is common practice: https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-controltido64 commentedon Dec 12, 2023
cc @kelset @Saadnajmi
cortinico commentedon Dec 12, 2023
@tido64 do you have suggestions on how to make it better?
tido64 commentedon Dec 12, 2023
Besides fixing all the issues? How about not making
run-iosdo so many things? Personally, I would prefer telling people to rundoctorinstead. You can add as many fixers as you want there instead.Edit: As for immediate actions: Make it opt in. Make sure its flaws are documented.
szymonrybczak commentedon Dec 18, 2023
So, we removed creating
react-native.config.jsfile frominitcommand in #2203. Also we re-generated diff for Upgrade Helper, so that when in 0.73.0 and 0.73.1react-native.config.jsis no more visible 👍We're now asking user if they want to install pods during
init, added in: #2204