Upgrading with react-native-git-upgrade makes no sense to me

almadsen commented 7 years ago

Upgrading with react-native-git-upgrade makes no sense to me. I'm getting lots of conflicts in project.pbxproj which also makes no sense. I try to solve them but Xcode keeps telling me it can't be opened. I don't se how this can be a conflict:

There are lines above the seems more similar to the theirs par but that is not treated as a conflict.

Is there some tool or some person that could help me with this or am I down to re-init the whole project?

rosiakr commented 7 years ago

I had the same problem during my upgrade. project.pbxproj is very touchy, and like you - I thought I knew how to resolve those conflicts and ended up with Xcode not being able to open the project. When you open with Xcode there should be an error with a corresponding stack. (mine was that _referenceProxy was NULL - meaning I had a line that didn't point to any existing entry PBXReferenceProxy section). The whole thing was a mess and I had to roll back to my previous version in git. One thing I will do differently going forward is make a back up copy of project.pbxproj BEFORE resolving conflicts. I think this new process of using react-native-git-upgrade is not very user friendly...

Xing-He commented 7 years ago

i had the same issue and then i resolved this by remove <<<<<< ===== and >>>>> ...

npomfret commented 7 years ago

Ugh, I'm trying to upgrade from 39 to 41, and even though I've not modified the at all since I've still got loads of conflicts in the project.pbxproj file. It just doesn't work, I think the only answer is to rebuild your project from scratch

fungilation commented 7 years ago

What is even a virgin project.pbxproj from RN? I'd just use a stock project.pbxproj from RN@0.41 and unlink/re-link native modules, instead of trying to resolve a thousand conflicts, but I don't even know which to use as there's multiple project.pbxproj littered around the RN code repository here.

Ugh.

npomfret commented 7 years ago

Prior to RN40 (i think) you could get a virgin project file by using react-native upgrade. I think it's gone now though, and I suspect we really need it back. Merging this file by hand simply isn't possible, at least not for me. I've got maybe a hundred conflicts in there, and I've barley changed it. There's just no way to upgrade now.

fungilation commented 7 years ago

I use these 2 regexes to replace the conflicted project file, to take out the ours sections and leave only the theirs:

^<<<<<<< ours\n[^>]*=======\n
^>>>>>>> theirs\n

This should, like I suggested, be an option in the new upgrade script. To add "all ours" and "all theirs", besides the current option of leaving all conflicts for in files.

ncuillery commented 7 years ago

@fungilation @npomfret There is nothing stopping you from using react-native upgrade. The command still exists.

fungilation commented 7 years ago

Sure. But this issue is about this being 2 steps forward 1 step back, when it can be just 2 steps forward. On Sun, Feb 19, 2017 at 12:11 PM Nicolas Cuillery notifications@github.com wrote:

@fungilation https://github.com/fungilation @npomfret https://github.com/npomfret There is nothing stopping you from using react-native upgrade. The command still exists.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/facebook/react-native/issues/12261#issuecomment-280944891, or mute the thread https://github.com/notifications/unsubscribe-auth/ADoJSl6DD95gdOzV9u17Sbny_uEGjxLBks5reKHHgaJpZM4L5q4q .

-- Cheers, Gary

thatjuan commented 7 years ago

I was excited about the new upgrade workflow until I had to use it. xcodeproj files are notorious for being really awkward to merge. I spent hours trying to manually fix about 25 conflicts and every single time I ended up with an unreadable file.

I've been thinking that approaching this issue by merging xcodeproj files is just not going to pan out. I think a better approach would be to programmatically re-construct your xcodeproj.

I assume the majority if not all of the conflicts come from customizing your xcode project by adding frameworks, changing compile targets, signing certificates, etc and then trying to apply the changes that the RN team makes on each release.

So the idea is to apply your changes to the xcodeproj programmatically with something like https://github.com/CocoaPods/Xcodeproj

This way you'd maintain a script that takes the latest xcodeproj unmodified as it comes from RN and then applies a set of deterministic changes to it. It could:

Add custom fonts
Add files
Set your codesign settings
Add targets
Add frameworks
etc.

It could also apply any changes required by RN packages that need xcode project changes.

I haven't had any time to tackle this, but I think it's a promising approach.

The first step would be to write a script that retrieves the corresponding unmodified xcodeproj from RN instead of trying to diff the current one.

Also worth noting that https://github.com/CocoaPods/Xcodeproj has an xcodeproj differ, which may also be useful.

Thoughts? Critique?

fungilation commented 7 years ago

This would be the much better approach for xcodeproj alone. On Sun, Feb 19, 2017 at 10:10 PM thatjuan notifications@github.com wrote:

I was excited about the new upgrade workflow until I had to use it. xcodeproj files are notorious for being really awkward to merge. I spent hours trying to manually fix about 25 conflicts and every single time I ended up with an unreadable file.

I've been thinking that approaching this issue by merging xcodeproj files is just not going to pan out. I think a better approach would be to programmatically re-construct your xcodeproj.

I assume the majority if not all of the conflicts come from customizing your xcode project by adding frameworks, changing compile targets, signing certificates, etc and then trying to apply the changes that the RN team makes on each release.

So the idea is to apply your changes to the xcodeproj programmatically with something like https://github.com/CocoaPods/Xcodeproj

This way you'd maintain a script that takes the latest xcodeproj unmodified as it comes from RN and then applies a set of deterministic changes to it. It could:

Add custom fonts

Add files

Set your codesign settings

Add targets

Add frameworks

etc.

It could also apply any changes required by RN packages that need xcode project changes.

I haven't had any time to tackle this, but I think it's a promising approach.

The first step would be to write a script that retrieves the corresponding unmodified xcodeproj from RN instead of trying to diff the current one.

Also worth noting that https://github.com/CocoaPods/Xcodeproj has an xcodeproj differ, which may also be useful.

Thoughts? Critique?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/facebook/react-native/issues/12261#issuecomment-280995957, or mute the thread https://github.com/notifications/unsubscribe-auth/ADoJSlXsjY_E4puYkP9upeGs_GkJr8BOks5reS5SgaJpZM4L5q4q .

-- Cheers, Gary

npomfret commented 7 years ago

A programatic way of adding my changes to a virgin Xcode project file would be ideal.

thatjuan commented 7 years ago

@ncuillery any comments on the above?

nhayfield commented 7 years ago

@thatjuan I got lucky and merged it right the first time. I agree its a pain. What I did was look for duplicate hashes and merge them by hand. If I didn't see a duplicate then I would just include both. Seemed to work. I really took my time and read through the code though.

ncuillery commented 7 years ago

I think a better approach would be to programmatically re-construct your xcodeproj.

A programatic way of adding my changes to a virgin Xcode project file would be ideal.

The link command already uses that kind of tool under the hood (this one).

If you want to be able to rewrite all the changes you need in the project.pbxproj programmatically, maybe you could write and maintain your own rnpm plugin to do the job, but IMO I don't think it will be more time-saving and easier than resolving 20 or 30 conflicts in the project.pbxproj. But I'm not sure that the link command (or any "pbxproj file reader/writer") can handle any change possible in the project.pbxproj file.

In fact, react-native-git-upgrade implements the merge approach, consisting in merging the RN changes into the user current sources whereas you people here seem to use the "override and rewrite" approach by using react-native upgrade as an "eraser". You used to run the upgrade command, answer "Yes" to every files in conflict, and then rewrite all the changes with the link command, am I right ? react-native-git-upgrade is simply not designed for this usage.

Of course, this approach is the most user-friendly (who likes resolving Git conflicts?), it could work on a simple project. If it's working on your project, go with it. But, like I said, not everything can be handled with 3rd-party librairies and react-native link (adding new a build configuration, assets, ...).

If you don't want to use react-native-git-upgrade at all, you should take a look at Exponent. I've never tried it, but when people complain on the RN community Facebook group, others say "don't bother and use Exponent" so I guess Exponent makes RN upgrades seamless 😄. There is also the create-react-native-app project (coming from the Exponent community, currently in alpha), which aims at a pure JavaScript development.

Let me share some pieces of advice about the merge approach, I hope it would help resolving the conflicts:

Upgrade yours RN versions one by one, even if the tool allows multiple updates at the same time. You'll get smaller conflicts, easier to reason about.
You can use a Git merge tool to resolve your conflicts (a bit tricky, should be improved, but possible)
You should have a basic understanding of the structure of the project.pbxproj file: focus and pay attention on the hashes, there is one for each part of your app, each target, each configuration (see the XCConfigurationList section).
Read the corresponding diff on rn-diff. It's important to know what has changed in order to resolve conflicts.
I explained how I've created this tool at the London React meetup last week, watch the talk to understand how it works (spoiler: there's nothing you can't do with a terminal and Git).

To conclude, I'd say that the proect.pbxproj is a burden we have to carry. This issue should be resumed as "Make a better upgrade documentation".

We could improve the Upgrade guide by adding:

what are we supposed to do with the conflicts delimiters (the current doc assumes that everybody knows what a Git conflict is, that is bad)
An example showing that removing the conflicts delimiters makes the project.pbxproj file corrupted (thanks to @dasblitz to have provided one: https://github.com/facebook/react-native/issues/12210#issuecomment-279220737 )
The tips & tricks mentioned above.

Let met bring @mkonicek @grabbou who could have an enlightened opinion about RN upgrades into this conversation.

fungilation commented 7 years ago

In fact, react-native-git-upgrade implements the merge approach, consisting in merging the RN changes into the user current sources whereas you people here seem to use the "override and rewrite" approach by using react-native upgrade as an "eraser". You used to run the upgrade command, answer "Yes" to every files in conflict, and then rewrite all the changes with the link command, am I right ? react-native-git-upgrade is simply not designed for this usage.

Close, but no. I look at diffs per file in the interactive upgrade and choose to keep and merge conflicts, or have it overwritten by new version.

react-native-git-upgrade is an improvement with the 3 way merging. It's just for project.pbxproj it's almost always too many to merge manually. So like I wrote in https://github.com/facebook/react-native/issues/12261#issuecomment-280932462, I regex my way to keeping only "theirs".

My process going forward would be to react-native unlink all native modules first, react-native-git-upgrade, then try merging and resolving project.pbxproj with hopefully minimal conflicts. Then react-native link all the packages again.

This is my process in what I see is the path of least resistance. Give my comment a like if others feel the same. If this is true then it makes sense for RN to add in further automation in resolving conflicts based on this, in special consideration of project.pbxproj.

ncuillery commented 7 years ago

My process going forward would be to react-native unlink all native modules first, react-native-git-upgrade, then try merging and resolving project.pbxproj with hopefully minimal conflicts. Then react-native link all the packages again.

I've never thought about that. Sounds good, I'll definitely test that.

grabbou commented 7 years ago

Just to put an additional context: there was an attempt prior to git-upgrade to create codemods-like mechanism for upgrading pbxproject. We wanted to use built-in ability to modify pbxproj to manually apply tweaks and changes to it (e.g. the initial beta was manually adding missing flags to build products). It didn't work out as there was too much overheat to write upgrade paths for every single braking commit and there were just too many weird combinations of project setup in the wild to handle.

I guess that if you want a smooth upgrade, try create-react-native-app or exponent. Otherwise, React Native is at the stage where braking changes can happen and none of the tools will save us from doing fixes manually (e.g. import paths that changed). The tools we have now may be helpful in the future, but that's only to happen when the framework itself stabilises.

The approach I use on regular basis is rather simple: I don't upgrade pbxproject. What I do is I upgrade react-native and hit run. In most cases, it works w/o any additional changes. When I hit into errors, I look in changelog to find out that e.g. a new flag has to be added. That works in 99% cases except when import paths change.

isbaek commented 7 years ago

I ended up downgrading back to the my previous RN version. My xcodeproject works at least for now, only as a temporary solution. It would be really good to see if someone can solve a workaround regarding the merging conflicts.

ericvicenti commented 7 years ago

cc @mkonicek

We're also working on a react-native eject step, which will autogenerate all the native code for your project. This would squash any local configuration you may have, but more and more things will eventually be configurable via the app.json file.

wachunei commented 7 years ago

I have the simplest project ever (https://github.com/wachunei/wifiuc-react-native), almost no linked libraries. I've tried to run react-native-git-upgrade, tried replacing ======= with ); where syntax looks like it should go.

But no, I can't do it. It's driving me nuts 😫.

I'd gladly take a PR that resolves project.pbxproj conflicts after running react-native-git-upgrade 🙃

See how it breaks syntax so you have to be extra careful.

thatjuan commented 7 years ago

Here's what finally worked for me. I took some suggestions from this thread and finally got my project up from 0.40 to 0.42 (I meant it to be 0.43, but didn't realize 42 is still "latest").

1. Create a new branch (e.g. upgrades/0_40-0_42) (optional)

This is to facilitate the process of undoing steps if needed.

2. Unlink all packages

As suggested by @fungilation, unlinking all packages reduces the number of differences between your project and the master project. In theory, this facilitates the merge.

The easiest way I found to do this was to copy all packages from packages.js (even those that don't need linking, and creating a command list like so:

react-native unlink react-native-randombytes
react-native unlink react-native-router-flux
react-native unlink react-native-vector-icons
react-native unlink react-redux
react-native unlink realm
react-native unlink redux
...

Then just paste them all in the console.

If you created a branch for the upgrade, commit now. git commit -a -m "unlinked all packages in preparation for upgrade"

3. Run upgrade

react-native-git-upgrade

Follow the upgrade instructions.

4. Merge

This is when you're likely to run into merge conflicts. The output of react-native-git-upgrade will tell you if there were conflicts and on which files. If your pbxproj file was successful, then you're in luck. Else, open your pbxproj file in your text editor and start searching for =====. The best strategy is to try and understand the changes. Try to identify duplicate files in the "ours" and "theirs" fragments and figure out which ones need to stay. Most often you can just keep both fragments, but beware of syntax (more details below).

There are two main issues that are common after merging pbxproj manually. The first is that xcode can no longer open it with an error similar to "...xcodeproj cannot be opened because the project file cannot be parsed". In other words, there's a syntax error in it. The second common issue is xcode crashing right after opening the project. This is technically an xcode bug, as it should never crash, but it generally means something in the file doesn't make sense.

I ran into both of these scenarios during this merge, and I found some tools that helped a lot in resolving them.

Resolving pbxproj syntax errors

It's easy to miss adding a closing } for a = { and a ) for a = (. Watch out for these as sometimes the merge process will add a new fragment that requires a new closing parenthesis and just use an existing one, leaving an unclosed fragment in your file.

I used xcodeprojer's --lint option to check my file after merging. If there's an error, it'll give you some information about the error. If it finds unused entries in the xcode proj, it'll output a patch you can apply:

xcodeprojer --lint my_project.xcodeproj > my_project.patch and then patch < my_project.patch

If there are no errors, it won't output.

Resolving xcode crashes

What I found the most useful in finding errors was to run xcodeproj show within the ios directory. Look at the beginning of the output of this command to see a list of logical errors in the xcodeproj. In my case, it said something like:

<PBXReferenceProxy path=`libRCTAnimation.a` UUID=`285C83481E22280B0009EE84`>` attempted to initialize an object with an unknown UUID. `285C83471E22280B0009EE84` for attribute: `remote_ref`. This can be the result of a merge and  the unknown UUID is being discarded.

I went in the file and looked for 285C83481E22280B0009EE84. Then I removed blocks referencing it. This solved the xcode crash.

5. Re-link your packages

After you're able to open your project in xcode again, re-link your packages:

Do the opposite of step 2.

react-native link react-native-randombytes
react-native link react-native-router-flux
react-native link react-native-vector-icons
react-native link react-redux
react-native link realm
react-native link redux
...

6. Merge upgrade branch (optional)

If you created an upgrade branch, test running your project first, and then merge it back.

Final thoughts

This process took about 2.5 hours. Perhaps because I was finding the tools and figuring things out while doing it. It's still not ideal and I don't look forward to the next upgrade.

I am thinking that a combination of a custom ios framework to hold things like assets, fonts, and other customizations that can be easily linked + unlinked, plus the process I described earlier in this thread to programmatically re-construct an xcodeproj for the project from RN's master is still the best solution.

I hope this is helpful for now, though.

npomfret commented 7 years ago

If you want to try @thatjuan's technique of unlinking your project before attempting the upgrade, then there's a node script here that will help with the unlinking process.

I tried, and still had loads of conflicts. I attempted to resolve them by hand but the resulting Xcode project wouldn't compile, it had some sort of low level linking error that I just couldn't figure out.

I ended up copying the virgin Xcode file from a clean AwesomeProject, replaced the name with my project name and then used Xcode to rebuild the whole project from scratch (I made and checked in plenty of notes for next time). I also noticed that there were changes in the default package.json file that were not picked up by the react-native-git-upgrade processes. Specifically the version of react had changed and the test dependencies had changed - but none of these changes were added to my package.json file after running react-native-git-upgrade.

Eyesonly88 commented 7 years ago

If you are still having issues after fixing syntax errors complaining about BundleIdentifier not found, here's what I did to solve it:

Remove the tv-os target in your xcode (select your project in xcode and right click -> delete on the tv-os targets.
Clean build folder through xcode (product -> clean)
Run npm start -- --reset-cache

Now running react-native run-ios should just work ™️ 🎉

fungilation commented 7 years ago

Note that I did react-native-git-upgrade from RN 0.41 to 0.42. Surprisingly no 3 way merge conflict this time in project.pbxproj. The most conflicts are in Info.plist instead, most of which is simply lines moved out of order. A programmatic rebuild would definitely be much better here that doesn't depend on order of lines.

manishtpatel commented 7 years ago

You guys haven't tried upgrading when using cocoapods, it will take IBM watson to fix pbxproj file.

I am leaning toward cutting the tie with react-native upgrades with ios changes. No more automated xcode changes, try to figure out what changed and if it is really important then manually make the change in xcode.

Just curious if anyone already done that, how is your experience with upgrades? I wish the react-native team releases changes made in xcode proj as instructions.

asbjornenge commented 7 years ago

You can use the following cmd if you want to accept theirs:

cat project.pbxproj | sed '/<<<<<<< ours/,/=======/g' | grep -v '>>>>>>> theirs' | grep -v -e '^$'

(works well if you do react-native unlink before react-native-git-upgrade)

PeterKow commented 7 years ago

Rn-diff saved me! https://github.com/ncuillery/rn-diff

Apply manually changes for your version using https://github.com/ncuillery/rn-diff/compare/rn-0.41.0...rn-0.42.3
commit
react-native-git-update
resolve file conflict with yours
done

You can alternatively branch out copy xcode all file and then merge it back to your main branch and resolve conflicts with some tools, but then it's step 1 anyway

cwRichardKim commented 7 years ago

@npomfret Can confirm that init-ing a new project (with the new upgraded react native locally) kind of worked. at least xcode isn't crashing anymore. I'm in the process of relinking all of the necessary libraries, but i feel pretty confident about it

edit: 3 hours of work total, but no issues. this is the way to go imo. @OriginalYellow I did the same thing with linting and all. To clarify, the steps I took were: 1) steps 1-3 of @thatjuan's advice (so that includes unlinking, though I'm not 100% sure that's necessary) 2) react-native init [same project name] in a different folder (make sure you are on the new version before you do this with: react-native -v) 3) delete (or move to a different file) /ios/[projname].xcodeproj and ios/[projname].xcworkspace (I'm using cocoapods) 4) move the /ios/[projname].xcodeprojfile from the new project to the old project 5) npm installand pod install (from wherever your pod file is) and react-native link 6) react-native run-ios (it broke here) 7) go through each of my dependencies to make sure all the installation steps were completed

OriginalYellow commented 7 years ago

I've got to agree with @npomfret and @cwRichardKim. I did everything @thatjuan said to do up to step 4, and the linter gave me the all clear after I fixed every merge conflict and applied the patch it generated. But in the end it still caused xcode to crash every time I tried to open the project. The safest way to do this seems to be just remaking the project from scratch.

npomfret commented 7 years ago

@cwRichardKim yes, creating a brand new project from scratch worked. After linking I had to do a bunch of manual steps, (which I've added to to some documentation now) such as

the version number
the deployment target
some manual linking (such as the CameraRoll module)
the versioning scheme
the provisioning profile management
team setting
launch images
various extra manual steps that are needed for some of my imported projects, for example Crashlytics needs a script adding as a build phase

It sounds like a lot, but now I've got it all noted down I'm confident I can have it all done in about an hour next time.

itinance commented 7 years ago

I wonder about react-native-git-upgrade is never upgrading the package.json-file, even if the RN-folders in node-modules point to the newest version then, in package.json the old ones remains.

holms commented 7 years ago

"react-native ugprade" is able to rewrite all files without merging anything, why react-natiev-git-upgrade doesn't have such option?? i have no idea what should i merge in here, android and ios folders are autogenerated anyway..

sospedra commented 7 years ago

@holms "Hey! With this tech you can forget about native code... Well, unless you want to update at any time" 🥇

rudyhuynh commented 7 years ago

It seems like the pain is about resolving conflict for project.pbxproj then make sure xcode can parse it successfully. My idea is using a parser (like this one: https://github.com/apache/cordova-node-xcode) to help identify parsing error of project.pbxproj, then we can fix it. It would be great if xcode can show more informative error instead of just "Project [...] cannot be opened because the project file cannot be parsed."

grabbou commented 7 years ago

Parsing project and doing things manually was what I am referring to in this thread as one of historical solutions. react-native uses that parser behind the scenes to make link and others work.

On Wed, 26 Apr 2017 at 06:18 Rudy Huynh notifications@github.com wrote:

It seems like the pain is about resolving conflict for project.pbxproj then make sure xcode can parse it successfully. My idea is using a parser (like this one: https://github.com/apache/cordova-node-xcode) to help identify parsing error of project.pbxproj, then we can fix it. It would be great if xcode can show more informative error instead of just "Project [...] cannot be opened because the project file cannot be parsed."

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/facebook/react-native/issues/12261#issuecomment-297233423, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWcxti49YUns-xEIpxpMN15f0ymKwI5ks5rzsWIgaJpZM4L5q4q .

hramos commented 7 years ago

Hi there! This issue is being closed because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we're automatically closing issues after a period of inactivity. Please do not take it personally!

If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.

fforres commented 7 years ago

Just to add to the conversation, i found out that kin https://github.com/Karumi/Kin works incredibly well to detect errors:

ERROR: line 569:3 missing ';' at 'name'
ERROR: line 570:3 missing ';' at 'path'
ERROR: line 571:3 missing ';' at 'sourceTree'
ERROR: line 572:3 mismatched input 'fileEncoding' expecting ';'
ERROR: line 906:3 mismatched input 'name' expecting 'buildRules'
ERROR: line 909:3 mismatched input 'name' expecting 'dependencies'

Seeing this in the end was really satisfying

λ kin
CORRECT

jiteshwadia commented 7 years ago

Hi, I got same error and this is how I fixed it after 3-4 attempts.

Go to your project/ios/path
right click on .xcodeproj file and select show package contents
Open project.pbxproj with any text editor. (I have used textedit).
make sure you can see the structure with proper indenting. (This will help you to recognize the mistake while editing the file. I reduced a font a bit to see it properly).
Delete >>>>>> ours, ======, <<<<< theirs
While deleting keep an eye on the structure, You might have to add some closing curly brackets, or some key-value pair code so that the edited value structure looks same as previous or next value.

Naoto-Ida commented 6 years ago

@fforres Kin worked amazingly for us. If only it could automatically fix those instead of just pointing them out...

I've pretty much added .flowconfig, .gitignore and *.pbxproj to .gitattributes with the option merge=union, then manually fix .pbxproj using Kin.

antonsivogrivov commented 6 years ago

I tried to update rn from 0.41.2 to 0.50.3, spent couple of days and lots of hours merging all this shit and trying to successfully build my project, but I stepped back and returned to 0.41.2

I faced with react-native-maps building problems (It happens in every f***ing update of react-native), react-native-fbsdk problems, and many other magical building errors with CocoaPods and BatchedBridge (or CxxBridge), Folly, Glog,.... oh my God! I just want to work with my awesome product, and don't want to struggle with frameworks!

But I need this update :( And soon I will try again.

WundrApp commented 6 years ago

I used xcodeprojer as mentionned by @thatjuan to solve this !

I first deleted all the <<<< ours, >>>>> theirs and ==== I had. Eventually replacing the ==== by };

Saved pbxproj file.

Then I copied my project.pbxproj file to a temporary folder and applied the xcodeprojer --lint project.pbxproj > my_project.patch command to it. It output one error on line 790 which I solved and my file open

kahitarich commented 6 years ago

I was able to resolve this conflict first backing up the file with conflict and then carefully resolving each conflict by hand. If my case I kept all the changes ("their" and "ours") but made sure that the }; were all correctly closed.

In some of cases I had to copy complete closures by copying line from earlier closures. For example:

<<<<<<< ours
        16325337ED944F57BE6F0B30 /* Frameworks */ = {
            isa = PBXGroup;
            children = (
                1222EEC0523740BDB4F97BFD /* CoreData.framework */,
                7D736096AB2B4626B7046D95 /* SystemConfiguration.framework */,
                B5E4D59920D7468E8D64C97D /* libz.tbd */,
                457A9EAE7B3B45C98AEDD311 /* libsqlite3.0.tbd */,
                61C2E7A3F9CC32901DB622B8 /* libPods-PAndDAppAuth.a */,
                5C7DC1068AE3E4F5204F5DBF /* libPods-PAndDAppAuth-tvOSTests.a */,
                77175699C0CB35B38A47AEB8 /* libPods-PAndDAppAuthTests.a */,
=======
        2D16E6871FA4F8E400B85C8A /* Frameworks */ = {
            isa = PBXGroup;
            children = (
                2D16E6891FA4F8E400B85C8A /* libReact.a */,
>>>>>>> theirs
            );
            name = Frameworks;
            sourceTree = "<group>";
        };

became

        16325337ED944F57BE6F0B30 /* Frameworks */ = {
            isa = PBXGroup;
            children = (
                1222EEC0523740BDB4F97BFD /* CoreData.framework */,
                7D736096AB2B4626B7046D95 /* SystemConfiguration.framework */,
                B5E4D59920D7468E8D64C97D /* libz.tbd */,
                457A9EAE7B3B45C98AEDD311 /* libsqlite3.0.tbd */,
                61C2E7A3F9CC32901DB622B8 /* libPods-PAndDAppAuth.a */,
                5C7DC1068AE3E4F5204F5DBF /* libPods-PAndDAppAuth-tvOSTests.a */,
                77175699C0CB35B38A47AEB8 /* libPods-PAndDAppAuthTests.a */,
                        );
            name = Frameworks;
            sourceTree = "<group>";
        };

        2D16E6871FA4F8E400B85C8A /* Frameworks */ = {
            isa = PBXGroup;
            children = (
                2D16E6891FA4F8E400B85C8A /* libReact.a */,
            );
            name = Frameworks;
            sourceTree = "<group>";
        };

philjoseph commented 6 years ago

Complexity of upgrade is still a major issue. I can understand that it is not top priority but this issue shall stay open and believe some of the advices here shall find their way to the official guide.

srameshr commented 6 years ago

Kin: https://github.com/Karumi/Kin Solved the problem for me. Just blindly added and removed lines as suggested by KIN.

falcon03 commented 6 years ago

I think that if this issue doesn't get solved and/or mitigated in some way the React Native upgrade process is so frustrating that developers should think twice to use this platform in the next project. At leas this is the case for me, I've already spent a few hours trying to merge conflicts in project.bkxproj and I haven't got anything close to working yet. So frustrating!

Trying to upgrade from RN 0.50.1 to RN 0.55.3.

fungilation commented 6 years ago

Works fine for me. Upgrade 1 minor version at a time with react-native-git-upgrade <version> (ex. 0.50 -> 0.51, etc.)

facebook / react-native