Upgrading React Native

[cpojer]

This issue is part of What do you dislike about React Native?.

The top voted answer was that upgrading React Native is painful, see #64 (comment).

The problem statement is very broad ("Upgrading is hard") and we would like to gather more context about the actual issues that people are experiencing. Please use this issue to list every piece of content you can related to upgrading React Native: your own stories, links to issues, blog posts, complaints or any other rants you can find. Thank you!

[xzilja]

For me, usage of tools like react-native-git-upgrade made upgrade process more complicated rather than easy i.e. bunch of issues and unexpected inconsistencies. I found manual upgrades much easier. There is this repo https://github.com/ncuillery/rn-diff that shows diff between react-native versions, its easy to follow and outlines changes very clearly (Besides when XCode files change, these can be hard to figure out).

[janhesters]

General 💬

What I dislike most about upgrading React Native is the amount of time it takes to do it properly and how bug prone it is. In my opinion the uncertainty while upgrading is worse than the time it takes.

(DIsclaimer: I love RN and the great work you guys do. Just the fact that you started that dislike thread is highly appreciated. I hope this doesn't come off as too whiny ❤️.)

Time ⏰

Let's say you are only one version behind the latest release. Then it's not that bad. You go to the changelog and you read it. You upgrade your package.json run npm install and take optional steps into account that are mentioned in the changelog. So far so good.

Here comes the first twist. If all goes well this process only takes you about 10 minutes. But, depending on the changelog, this might also take anywhere between 10 minutes and several hours. Especially if some native iOS or Android code has changed.

And now multiply this by several versions if you fallen more behind. This just means a lot of effort.

Bugs 🐛

If you, while upgrading, accidentally miss just one step it can destroy your whole project. This makes upgrading even more exhausting. You will have to stay highly concentrated and focused, 'wasting' your mental energy that could've been spend in your own codebase. Because the stakes are so high (again one missed step could mean hours of debugging) this process is so uncomfortable.

Again this effect is multiplied the more versions you have fallen behind.

What this has trained me to do 🎓

After I had a couple of bad experiences with upgrading React Native, I learned to just make a new project, copy my code, reinstall all the pods, re-link all dependencies and re-add the Java code. Even though this takes (depending on the project size) between 1 and 6 hours, it's way more predictable (both in the time it takes and in the quality of the outcome: a working project). This is probably not what you guys intent us developers to do.

Ideal solution 🙏🏻

I think from a developer experience the best thing would be to have some command that just upgrades the projects automatically. This would tackle both pionts, it would make it fast and easy. But as I mentioned in the beginning (for me) the time is less of a problem. So a quick fix would be to release a clear step by step guide / tutorial with each new version on how to upgrade, so we could just follow it (more or less) blindly.

Let us the community know if we can help in any way. And thank you again! ❤️

[noahtallen]

To expand on the automated upgrade tool thought, I find that it typically tries to overwrite most every change in my native files. For instance, though our app is pure react-native (with one or two small native modules), we plenty of custom configurations in Xcode and in gradle for managing dependencies. Nothing massive. But it means that when it comes time to upgrade, the automatic tools typically fail because they try to change stuff that I changed in the project files.

Additionally, I've tacked on a ton of various postinstall scripts (for npm and for gradle/pods) to fix various build issues that have cropped up over the months. It'd be nice to know which of those "hacks" can be safely removed at this point! (Here's a hack that I believe was suggested in the changelog a couple of versions ago: "postinstall: "cd node_modules/react-native; exec ./scripts/ios-install-third-party.sh; cd third-party/glog-0.3.5; exec ./configure; cd ../../../..")

To me, the process of upgrading react-native should be as simple as:

1. Update the version number in package.json
2. npm install or similar
3. Fix our own (non-project configuration) JS code, or native modules code which is affected by the upgrade.

I think it would also be very nice (for ejected projects, anyways) to specifically utilize pods for react native by default (instead of manual linking), because the entire community ends up relying on pods for 3rd party packages like camera modules, or react-native-firebase, etc. Managing both manual linking and pods is a challenge since it's not clear exactly which route you're supposed to go, and I think it messes with the upgrade process. React-native shouldn't have to touch much of the project configuration stuff after its first installation, at least in my mind.

[kelset]

to list every piece of content you can related to upgrading React Native

Since I've been investigating this issue lately, following the extraction of the CLI, here are some bullet points that will help contextualize & reference:

• latest stable was 0.57, released in September, and since then we have been doing patch level releases. Overall there have been 5 "major/stable" releases (0.53 to 0.57, with 0.58 currently in rc) this 2018.
• the upgrade problem was discussed in August during a core meeting, here are the notes
• aside from the rn-diff repo (which is from the same author of react-native-git-upgrade), another popular article about upgrading I used a lot is this one
• a really cool in-depth experience of upgrading is by @tylergaw, who has been documenting it here
• here is the page of the docs related to upgrading

And, personal experience:

• I've been always almost doing the upgrades manually, similarly to @iljadaderko
• the main issue is always when Xcode project file has changes. Because that .xcodeproj is hellish to work with - using pods has helped a ton with it (related proposal)

[fungilation]

• I disagree that react-native-git-upgrade is/was a problem. When it works and it did work for me 90% of the time, it was the most painless way to upgrade. And I tended to upgrade pretty often, like every month or 2.
• Pods is nice, but only for iOS and not Android. Not saying it's bad to solve half the pain (and much in .xcodeproj files)
• rn-diff is nice, but it stopped being updated beyond 0.57.2? So for my upgrade from 0.57.5 to 0.57.7, I had to do it manually via react-native upgrade. Not fun, for just a minor release upgrade, yet I wanted to do it since there are a fair number of bug and crash fixes.

My suggestions for improving the Upgrade Experience:

• Update the official RN docs. Incorporate from good articles on upgrading linked by @kelset perhaps? Because the official docs are woefully out of date, with the first recommended upgrade option being react-native-git-upgrade which seems permanently borked.
• That leaves react-native upgrade as the only other good option it seems.
  So how about a revamp of react-native upgrade, to automatically incorporate what rn-diff does, combined with 3 way merging of react-native-git-upgrade? The cli would:

1. Compile list of userland config files that react-native upgrade currently prompts for keeping or overwriting, but chop it down to a subset for which the virgin versions actually changed between the user's current RN version, and the RN version it's being upgraded to (automated rn-diff)
2. Attempt 3-way merge of these files that actually changed between RN versions
3. On failing 3-way merge, show conflicts either in cli or just in files (as react-native-git-upgrade did)

(1) does require additional file change tracking on every RN release, but I think the automation for users would be worth it in making upgrades painless. The file change tracking like what rn-diff does could be scripted as part of the RN release process?

[fungilation]

This new react-native upgrade would need to know the from and to versions of RN upgrade. Either supplied by user, or do it like react-native-git-upgrade did, handling the git/npm/yarn upgrade part as well. Requiring cli args for from and to versions would be fine to me, as the pain that needs fixing is handling what and how files need upgrading, not the yarn add react-native@x.y.z part.

[bdrobinson]

The fact that RN ships uncompiled code and requires you to hook into its Babel setup meant we had a lot of trouble in the upgrade to 0.56 (I think it was that one – the one that moved to a Babel 7 alpha) because it broke compatibility with Jest. Obviously keeping Jest working isn't strictly RN's problem, but the bigger issue was that RN shipped uncompiled code and requires you to adopt its babel config, and some subtleties in that had broken Jest in a few ways – see facebook/react-native#19859 and facebook/react-native#20614 where people had to resort to weird hacky workarounds to keep things working.

Again, those bugs and workarounds might be a Jest issue rather than a RN one, but having RN imposing constraints on the Babel setup definitely exacerbated the problem. It also seems to me that Babel is a pretty orthogonal concern to RN so it seems odd for RN to want to manage my babel config, and also adds obstacles for people wanting to keep on the latest RN version only to find they need to start adding mysterious packages like babel-core@7.0.0.bridge and tweak yarn resolutions to keep their code running.

Perhaps I'm missing something obvious in this (if so then do let me know!), but I can definitely vouch for the fact that it caused me a lot of pain!

I really appreciate the RN team engaging with the community in ways like this – thank you!

[MoKhajavi75]

Well, i know this is wierd but i rename the current project folder (i.e add an extra x) and use react-native init NAME then copy the .git folder from last folder and continue to configuer the project! 😁