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

Upgrading React Native #68

Open
cpojer opened this issue Dec 11, 2018 · 40 comments

Comments

@cpojer
Copy link
Contributor

commented Dec 11, 2018

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!

@cpojer cpojer changed the title Upgrading React Native Issues when upgrading React Native Dec 11, 2018

@cpojer cpojer changed the title Issues when upgrading React Native Issues from upgrading React Native Dec 11, 2018

@cpojer cpojer changed the title Issues from upgrading React Native Upgrading React Native Dec 11, 2018

@IljaDaderko

This comment has been minimized.

Copy link
Member

commented Dec 11, 2018

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

This comment has been minimized.

Copy link

commented Dec 11, 2018

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

This comment has been minimized.

Copy link

commented Dec 11, 2018

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

This comment has been minimized.

Copy link
Member

commented Dec 11, 2018

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

This comment has been minimized.

Copy link

commented Dec 12, 2018

  • 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 comment has been minimized.

Copy link

commented Dec 12, 2018

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

This comment has been minimized.

Copy link

commented Dec 12, 2018

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!

@MohamadKh75

This comment has been minimized.

Copy link

commented Dec 14, 2018

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! 😁

@simonbengtsson

This comment has been minimized.

Copy link

commented Dec 30, 2018

Just wanted to add that for us upgrades has been fairly smooth. Basically:

  1. Update version number in package.json
  2. npm install
  3. pod update
  4. Clean build both android and iOS

We would probably continue doing this even if an automatic tool came out since we want full control over the process with non react native libs and custom build scripts. I should mention that we started using react native quite recently and have only upgraded major version twice. Once from 0.54 to 0.55 and then from 0.55 to 0.57. It took more than a minute each time but not over what I expected. For us it takes about the same time as upgrading other native libs.

For us it was not the upgrades but rather integrating libs such as react native firebase and get everything to build with swift (facebook/react-native#16039 etc) and latest android that has been problematic. We accumulated a bunch of postinstall fixes in 0.54 and 0.55 for both platforms, but they could all be removed in 0.57.

@TheSavior

This comment has been minimized.

Copy link

commented Jan 4, 2019

There are a bunch of different ways upgrading React Native projects can be problematic, all of which probably have different solutions.

Some different areas that come to mind:

  • Updating your xcode project because configuration changed
    • Similar but more specific, keeping 3rd party iOS plugins linked after upgrading
  • Updating your Android project because configuration changed
    • Similar but more specific, keeping 3rd party Android plugins linked after upgrading
  • Updating native iOS code because RN APIs changed
  • Updating native Android code because RN APIs changed
  • Updating JS code because RN APIs changed
  • Upgrading your project and finding that 3rd party libraries don't work with this version yet

It would be helpful to get a sense if a specific one is the majority of the problems, frustrations, and time or if it is spread out evenly across all of them.

@JofBigHealth

This comment has been minimized.

Copy link

commented Jan 4, 2019

@TheSavior In our experience upgrading issues are mostly straightforward to resolve with careful piecewise upgrading of each 3rd party JS package. The biggest issue is mission-critical Android 3rd party libraries not being maintained which either a) means they are no longer compatible with the latest RN b) (more commonly) no longer compatible with the necessary versions of Android we need. We've never had issues with native or JS APIs changing regarding our own code - RN gives ample warning for the JS ones and the native Java/ObjC decorators/APIs seem pretty static these days.

In general the biggest issue in the RN community is maintenance and quality of 3rd party packages that contain native code. We've found the test coverage and testing to be of mixed quality, let's say. Why that's relevant to upgrading is that we've found breaking point releases to be much more common here than with web.

Slightly off-topic, one thing that stings us repeatedly is that RN requires Android Studio 3.1.x as of 0.57.7. Unfortunately the temptation to press on one of the many prompts Android Studio gives you can be overwhelming which results in a lengthy downgrade process. Another example is onboarding new devs who already have 3.2.x installed.

Hope that helps.

@fungilation

This comment has been minimized.

Copy link

commented Jan 4, 2019

@TheSavior, third party and first party code needing to keep up to date with RN API changes can't be RN's responsibility (other than clearly documented obviously), so doesn't need to be part of this discussion. But as far as what can be improved and automated for each RN upgrade, minor and major (especially minor ones as those shouldn't have breaking API changes). Would you and your FB colleagues take my suggestion into consideration?

Especially since react-native-git-upgrade is currently in a unusable state. Any scripted path for upgrades would be great.

PS. @JofBigHealth I'm on RN 0.57.8 and Android Studio 3.2.1 works fine with me. Mind you, I don't use the IDE, only the emulators and cli.

@brentvatne

This comment has been minimized.

Copy link

commented Jan 4, 2019

In general the biggest issue in the RN community is maintenance and quality of 3rd party packages that contain native code. We've found the test coverage and testing to be of mixed quality, let's say. Why that's relevant to upgrading is that we've found breaking point releases to be much more common here than with web.

In this blog post I describe a plan to make the Expo SDK completely modular, so you can install any part of it (eg: camera, video, sensors) and just use that bit if you want. In other words, they will be installable like any other react-native package. Hopefully having a large set of native modules like this available and actively maintained will help alleviate this pain. That said, we don't always track the latest version of React Native at Expo because we have our own release cycle and it takes time to update everything for the latest API changes, so you may have to be a version or so behind to take advantage of this. An example of what this looks like in practice is here: https://github.com/expo/unimodule-playground/blob/master/App.js - we're in the process of converting more of the APIs to be modular in this same fashion.

@TheSavior

This comment has been minimized.

Copy link

commented Jan 4, 2019

@fungilation, we are always happy to improve the docs. Send some PRs to update it and make it more clear!

For the other part about tooling around react-native upgrade, I think these tools are great to paper over some fundamental problems in the most user friendly way possible. For now, I'd prefer we understand the root causes and see if we can make improvements to the underlying infrastructure. Hopefully that can make higher level tooling simpler and more robust.

@joegoodall1

This comment has been minimized.

Copy link

commented Jan 4, 2019

It would be helpful to get a sense if a specific one is the majority of the problems, frustrations, and time or if it is spread out evenly across all of them.

@TheSavior I've done quite a few RN upgrades on a number of different projects so, through trial and error, have become quite familiar with common problems. This repo has been a big help.

The one area which I continually have problems with is the .xproj file 😭🤯. There may well be a better way of doing it but I invariably end up manually editing the file.

@fungilation

This comment has been minimized.

Copy link

commented Jan 4, 2019

A better updated one than rn-diff is https://github.com/pvinis/rn-diff-purge

@joegoodall1

This comment has been minimized.

Copy link

commented Jan 4, 2019

Thanks, @fungilation, wasn't aware of this.

@bondparkerbond

This comment has been minimized.

Copy link

commented Jan 4, 2019

Things I would appreciate to make upgrading easier:
A perfect world would have me just run the cli upgrade tool and it all just work. Barring that:
-Support for the latest Android and iOS versions, especially around things like latest stable Java, gradle versions, etc.
-Officially allowing and documenting 2 or more recent gradle, AS, Xcode, etc. versions for a specific RN version so we can upgrade RN version without needing to upgrade gradle/native versions and/or upgrade native/gradle/etc versions without needing to upgrade RN at the same time would help break the upgrade process into smaller, more manageable chunks and would hopefully make it easier. Ie: being able to upgrade one thing (rn version) today, then at a later time upgrade the other thing(xcode version) instead of it being so all or nothing)
-making it easier for us to upgrade RN packages through any of the following:

  • making a cli tool that is just focused on upgrading Android only and/or iOS only packages to make it easier for package maintainers to update packages for each new release (probably easier than making a cli tool to upgrade an app with many packages and would fix the bigger problem of needing upgraded npm dependency versions before being able to upgrade to a new RN version)
  • having a central location to document what versions of what npm packages work with which RN versions (maybe people upload their package.json and/or lock files before and after upgrading and we use that info to say which versions are known good together as a first step when updating before going into each packages github and spelunking it to see if it supports latest RN version and what version of the package to use. For example it would be nice to know that versions 2.x and 3.1 of package Y are known to work with RN version 57.0)
    -something that documents upcoming breaking changes on the native side(but targeted at RN devs) and maybe even helps with a code mod or explain what (if anything) needs to be changed specific to RN apps (ie: change compile to implementation on Android, do X to support Y new native feature better, etc.)
    These are just some random ideas, hopefully one or two of them might be helpful, but only time will tell! Thanks for all your hard work!
@zinoviev

This comment has been minimized.

Copy link

commented Jan 4, 2019

Just sharing the last time(nov 18) upgrade attempt:

  1. Execute git upgrade
  2. get tons of xcode xml file conflicts(was something like 51 to 57 jump)
  3. Spend hours to make project compilable again
  4. Realize even after you were able to compile and run the project, something is broken inside - weird layout issues, dev panel not working etc and you have no idea what was wrong
  5. Being upset and hold on an upgrade unless you really have to. And probably it will be bootstrapped clean new project and moving the app from the old project to the new one and manually link native deps one by one

Oh and not to forget - we are suffering from facebook/react-native#19569 and facebook/react-native#21168 per development machine installment. These bugs probably already fixed in higher versions, but at this moment it's less expensive than upgrade process.

@cipriancaba

This comment has been minimized.

Copy link

commented Jan 5, 2019

For me, it has to be upgrading the android project and dependencies, and all those overrides of build tool version, gradle, and so on.. Not necessarily rn's fault, but definitely something that could use better tooling?

Also, it's not really clear for each rn version what are the requirements, what build tools, gradle and so on to use..

@pvinis

This comment has been minimized.

Copy link
Member

commented Jan 7, 2019

I have also eliminated the annoyance of upgrading with the cli tool, by using what @fungilation said, https://github.com/pvinis/rn-diff-purge (i am the creator). It's basically what @MohamadKh75 said. It deletes the project, creates a new one, diffs. Then, when I have the diff, it's really easy to just do the changes in my actual rn projects. No more upgrading problems. Of course it kinda sucks that it's solved by a third-party thing but hey, that's what js/npm is all about, right?

@danielmartinprieto

This comment has been minimized.

Copy link

commented Jan 7, 2019

@pvinis would you main explaining the difference between rn-diff and rn-diff-purge?

@SaraChicaD

This comment has been minimized.

Copy link

commented Mar 22, 2019

Upgrading RN - The First 80%

We upgraded from 55.3 to 59. I ended up having to make a completely new project w/the CLI, reinstall all the dependencies, move over our files, and update the build.gradle & Info.plist manually. Then I updated navigation & that was 80%.

Here are those steps:

  • clone new project via RN CLI (started at 58.6 but then 59 came out while we were still trying to get that to work)
  • Upgrade Java per here
  • We had to update to support 64 bit binaries manually using this and this
  • Had to manually upgrade Android Plugin to v3.3.1

Upgrading RN - The Remaining 20%

Then we thought we were done -- and remote debugging would not work -- a dealbreaker. We were about to post an issue on the RN repo when we ran into this issue that addressed the same problem. Kudos to the team for fixing it in, like, an hour, and once the replied to our question, we had to clone a new project, uninstall & reinstall RN then it worked!

The out-of-the-box babel.config file didn’t work, so we had to upgrade that per this to this:

module.exports = function (api) {
  api.cache(true);

  const presets = [ "module:metro-react-native-babel-preset", "module:react-native-dotenv" ];
  // const plugins = [ "transform-remove-console", "transform-remove-console" ];

  return {
    presets,
    // plugins
  };
};

The rest was a bunch of weird gradle errors, having to update dependency build.gradle files with higher versions, babel.config stuff & the extracted modules not working. We gave up & are still importing them from RN.

With regard to issues with NetInfo, AsyncStorage and Slider, I made an issue here for NetInfo. Long story short, when we install & try to import them we get red screen errors that will not resolve unless we uninstall & import from RN; we were able to get AsyncStorage to work on Android but it crashed on device. Here are some of the error messages we were getting:

Screen Shot 2019-03-13 at 10 09 09 AM

Screen Shot 2019-03-13 at 12 08 07 PM

Issues Remaining

We will have to circle back to re-install as stand alone libraries AsyncStorage, NetInfo and Slider next time we upgrade. Also the react-navigation (I know that's not y'all, but it's a core library) essentially breaks for Android. We had to downgrade react-native-gesture-handler to 1.0.14 so that it wouldn't crash, but on Android once you open the drawer you cannot close it. Not ideal, hoping this is fixed in a subsequent upgrade. Just tested that on react-navigation 3.5.1 and react-native-gesture-handler 1.1.0 this issue persists. Here's the error we get for that:

Screen Shot 2019-03-15 at 2 11 39 PM

Everything works now out-of-the-box on Android for installDebug but assembleRelease requires me to go through the build.gradle files of 4 of our core dependencies and update the app versions to 28, or to match our own app's build.gradle. Here's an example of that error:

> Task :react-native-events:verifyReleaseResources FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':react-native-events:verifyReleaseResources'.

We also get images randomly ending up in our res folder that we have to delete every time we do assembleRelease:

* What went wrong:
Execution failed for task ':app:mergeReleaseResources'.
> [drawable-xhdpi-v4/node_modules_reactnavigationstack_src_views_assets_backicon] /Users/sarainescalderon/Documents/.../android/app/src/main/res/drawable-xhdpi/node_modules_reactnavigationstack_src_views_assets_backicon.png       [drawable-xhdpi-v4/node_modules_reactnavigationstack_src_views_assets_backicon] /Users/sarainescalderon/Documents/.../android/app/build/generated/res/react/release/drawable-xhdpi/node_modules_reactnavigationstack_src_views_assets_backicon.png: Error: Duplicate resources
  [drawable-xxhdpi-v4/node_modules_reactnavigationstack_src_views_assets_backicon] /Users/sarainescalderon/Documents/.../android/app/src/main/res/drawable-xxhdpi/node_modules_reactnavigationstack_src_views_assets_backicon.png     [drawable-xxhdpi-v4/node_modules_reactnavigationstack_src_views_assets_backicon] /Users/sarainescalderon/Documents/.../android/app/build/generated/res/react/release/drawable-xxhdpi/node_modules_reactnavigationstack_src_views_assets_backicon.png: Error: Duplicate resources

Screen Shot 2019-03-20 at 2 27 25 PM

@pvinis

This comment has been minimized.

Copy link
Member

commented Mar 25, 2019

@SaraChicaD hello. I have 2 questions for you because I'm curious.

  • how exactly did you try to upgrade in the beginning?
  • the netinfo problems, you had them after importing it from react-native-community/react-native-netinfo? I thought 0.59 had these libs still bundled, no need to import from RNC yet.
@SaraChicaD

This comment has been minimized.

Copy link

commented Mar 25, 2019

@pvinis

  • i don't understand what "in the beginning" means. we started in 40-something, and would just install and follow the release notes. we got stuck at 55.3 despite the upgrade tools and release notes, we couldn't get it to work
  • this official blog says they are deprecated, so i'm not sure which official source is the "right" one.
@cpojer

This comment has been minimized.

Copy link
Contributor Author

commented Mar 25, 2019

@SaraChicaD thank you so much for writing such a detailed summary of all the problems you were running into. It's certainly frustrating that you had to go through this and I hope we can figure out ways to improve this situation going forward.

@pvinis

This comment has been minimized.

Copy link
Member

commented Mar 27, 2019

@SaraChicaD

We upgraded from 55.3 to 59. I ended up having to make a completely new..

how did you "end up" there? how did you try to upgrade before making the new project? what did you do?

@SaraChicaD

This comment has been minimized.

Copy link

commented Mar 27, 2019

hi @pvinis i answered this question already. i don't understand what you're asking that i didn't already outline there, if you have more specific questions that would be helpful.

@pvinis

This comment has been minimized.

Copy link
Member

commented Mar 27, 2019

so:

  • you started with the project at 0.55.3
  • you opened package.json and changed the rn version to 0.59.0
  • yarn install
  • maybe something more?
  • you decided to rn init

is that how it went? I'm asking to know all the steps you took, to see if we need to make some upgrading steps more clear to people. :)

@SaraChicaD

This comment has been minimized.

Copy link

commented Mar 28, 2019

Ok @pvinis thank you for clarifying. We had tried to move from 55.3 to 56 and 57 various times before. We would get red screen errors about various things, review the release notes, mess with the babel config, build.gradle or whatever, try a bunch of things to get it to work, and give up. We did this at least twice, spending several days re-reading release notes, changing things, review Github issues, SO questions, etc.

Thus, when upgrading (initially to 58.6) we decided to sidestep fighting with the existing code and start fresh.

This is when we did react-native init, and then everything else described in my original post. Is this helpful?

@pvinis

This comment has been minimized.

Copy link
Member

commented Mar 28, 2019

yes. ok so you never tried to use rn-diff the original one, or react-native upgrade or something. always you tried to just change the package.json version. good to know so we make this more clear to users that upgrading needs more than just that.

@SaraChicaD

This comment has been minimized.

Copy link

commented Mar 28, 2019

@pvinis thanks for your follow up, i believe in the 2/3 times we tried to upgrade to 56 or 57 we tried react-native upgrade but to no avail (still red screened or had broken things) and also may have tried rn-diff but nothing we tried ever got us there -- which is why it made sense for us to just start from scratch. at one point i was able to get iOS to 56 but Android would fail with this:

571289376-Screen Shot 2018-08-25 at 11 19 03 AM

@noahtallen

This comment has been minimized.

Copy link

commented Apr 8, 2019

I'm just tackling an update from 0.58.3 to 0.59.3. There are some other things I intend to do as well:

  • Update react-native-firebase
  • Make the jest tests pass again (for some reason, on 0.58.3, our test configuration got messed up and we never got around to fixing it).
  • Update as many other deps as we may need to (e.g. react-native-maps, etc)

I'm going to outline how this process went for me so that y'all have some more info on how this typically goes for an app with a lot of dependencies!

Starting out:

  • Ran yarn global add react-native-cli to make sure I had all the latest version with the new upgrade tool.
  • ran react-native upgrade and immediately got this:
    Screen Shot 2019-04-07 at 9 29 57 PM
  • Ok... so I must not have the latest version. Looking at npm, react-native-cli was last published two years ago. Oof!
  • After some digging, it looks like there is @react-native-community/cli? I installed that globally and tried again, but got the same error. Not sure what's going on here. I'm really confused because this seemed to indicate I just needed to install react-native-cli.
  • I then tried removing the old one: yarn global remove react-native-cli and then tried again. Seems to be using the latest upgrade tool now!
  • Ok. The upgrade failed. :(
    Screen Shot 2019-04-07 at 9 41 52 PM
  • One unfortunate part of this is almost the entire error log of the upgrade tool is useless. It says

Most of the files are upgraded but you will need to deal with some conflicts manually

  • but the truth is that none of the files got upgraded except for the react-native & react versions in the package file!
  • It also says that I need to resolve conflicts - but there are no conflicts. It just failed.
  • Alright, so I think I'll have to go the manual route, comparing versions with rn diff purge.

Manual Upgrading: JS Portion

  • Alright, I'm gonna start by upgrading the package.json. I'll make the specific changes for package.json first.
  • There seem to be a ton of changes to dev-dependencies. It looks like we can get rid of "babel-core": "^7.0.0-bridge.0"; I hope it doesn't break anything!
  • Also updating flow-bin even though that is not in the package. It'll be needed for the flow dependency in the flow config file.
  • babel-eslint is in my setup, but not in the sample app... hm, I wonder if I need that. Gonna try to avoid a rabbit trail now, but I'll put a todo on it.
  • Alright, now installing those packages.
  • Huh, looking at it, it appears that I have a rather length postinstall step because of various issues in previous versions of react-native. It looks like this:
"postinstall": "rm -f ./node_modules/react-native/local-cli/core/__fixtures__/files/package.json; cd node_modules/react-native; exec ./scripts/ios-install-third-party.sh; cd third-party/glog-0.3.5; exec ./configure; cd ../../../..",
  • I wonder if I can dump all that. I bet I can. I'm gonna delete that whole line. The problem is, nothing would blow up now... it might take a while for whatever is cached to disappear.
  • Ok, since that's true, I'm going to stash real quick, install the old stuff again, then pop the stash and re-install again so that it doesn't run that script again. Looks good so far.
  • I made the small tweaks to the flow config and added the new metro config file. That appears to be all the js changes I need to make, so long as no packages got deprecated that I use. And so long as all my dependencies keep working, which seems unlikely.

Manual Upgrading: iOS Portion

  • Alright, now to test it asap on iOS, which has less things to change than android.
  • I've been getting this bug, which has not been closed yet, so I'm concerned about the workaround code I have. The changes to react-native are right around that same area. I think I'll comment my code and hope that the issues are resolved.
  • Those changes were pretty easy to make. Now to pod install, which was also easy this time because I managed to get react-native only importing via pods. So I don't have any part of react native manually linked.
  • Now to test it out! It built successfully and the app loaded right up. However, I navigated to one specific screen and got an immediate error:

Screen Shot 2019-04-07 at 10 07 54 PM

- At first thought, this seems to be an issue with `react-native-svg`. However, it could also be an issue with the transpiler. I'll try updating react-native-svg first. - I had to bump the package version, npm install, pod install, and restart the packager. Yep, that fixed it! Yay!

Looks like iOS is working pretty well for now! I was surprised firebase and react-native-maps played well with the update! Now on to Android.

Manual Upgrading: Android Portion

  • Looks like there are a lot of files to change. Might take a while.
  • The app level gradle file was easyish to change, but I'm not sure why there's now a debug version of AndroidManifest. That's not in my file structure anywhere, so I'm just not gonna add it. It also doesn't seem as if any changes to the main manifest file are necessary.
  • The changes to the project level build file were also easy, but I'm concerned that I might have to touch some of the other things, like supportLibVersion, or googlePlayServicesVersion. I also appear to be doing classpath 'io.fabric.tools:gradle:1.25.4 and I'm not sure what that's for anymore since it's not in the main package.
  • It seems as if that's all I need to change for now. To the testing!
  • Looks like I gotta open Android Studio since my emulator won't launch from the CLI. Might as well update android studio at this point.
  • Oh, and my emulators need updating. I guess today is update central.
  • I knew I'd have to touch react-native-maps:
ERROR: Unable to resolve dependency for ':react-native-maps@debug/compileClasspath': Could not resolve com.android.support:support-compat:26.1.0.
Show Details
Affected Modules: react-native-maps


ERROR: Unable to resolve dependency for ':react-native-maps@debug/compileClasspath': Could not resolve com.android.support:support-annotations:26.1.0.
Show Details
Affected Modules: react-native-maps

// etc. I think there at least 10 other similar messages regarding it
  • I actually had to investigate this last time. I actually had to downgrade gradle to get it to work. It was something with the react-native-maps config, so I'll try to upgrade it now. I think they fixed the issue they were having.
  • darn. It's only in rc. Gonna wait since people are claiming to have some issues with other things on iOS. This is really frustrating because it's currently impossible to install react-native-maps alongside the latest version of react native without changing stuff in the gradle file.
  • I tried downgrading the gradle classpath, but immediately started getting a different error:
Could not get unknown property 'mergeResourcesProvider' for object of type com.android.build.gradle.internal.api.ApplicationVariantImpl
  • After some short googling, I'm not sure I'll be able to upgrade react-native without keeping the higher gradle versions. I'd like to keep those. I guess I'll just hit off of react-native-maps rc for now.
  • Looks like the gradle sync is successful now!
  • At this point, I also did a quick test on iOS with the new maps version (after pod install, etc), and it still works.
  • Still trying to get android to work. After the first build from android studio, having manually started the packager, it said it couldn't find the dev server.
  • Then, I tried react-native run-android, which failed the first time. But the second time I ran it, the build succeeded. Note that I had stopped the packager previously.
  • The first time the app opens on the emulator, it does the classic "react-native version mismatch" error - which I usually resolve by running adb reverse tcp:8081 tcp:8081. I did so, and then reloaded the simulator. But now, it says "Could not connect to the devlopment server" again.
  • I tried resetting the cache on metro and the packager to no avail. Still getting version mismatch every single time.

Screen Shot 2019-04-07 at 11 02 29 PM

  • I would highly recommend clarifying this error. For one, I experience this error all the time, but it's rarely the actual problem. I haven't been on version 0.50.1 for many months, and I can generally run the app fine on Android with no issues for quite a while. I have no other apps running react-native, so it's unlikely the version is cached anywhere from a different dev server or something. I also never get this issue on iOS, only Android. Come to think, I think I may have gotten the issue on iOS, but it was actually the issue there: I had forgotten to bump the package.json version.
  • The error is most likely just that it can't connect to the dev server. So I try to open the dev settings to see the bundler URL..... and it crashes. Welp.
  • I also verified that the packager is the only one running on 8081, so it shouldn't be conflicting with anything. Hm.

So at this point, iOS seemed to update fairly easily, but Android has yet to work. I'll update this post as I make more progress on it. I have spent a little over two hours on the update so far. I hope this is helpful in understanding the pain we often have to go through while updating our projects. Even with the new upgrade tool, it's likely I would have still encountered the errors with the 3rd party libraries. I don't have any specific thoughts on this at the moment, but I hope anecdotal evidence is helpful as the team discusses the future of react native. :)

@noahtallen

This comment has been minimized.

Copy link

commented Apr 14, 2019

I've been diving back in today. I think it might be beneficial to continue the story, but let me know if this isn't the right place ;)

In between all this, I fixed the jest tests and did a bunch of work improving our eslint config, including to add prettier. While I was doing this, I couldn't extend react-native-community's eslint config and the prettier config at the same time. There was some kind of conflict. That's beside the point, though. :P

Updoot-ing

  • I first bumped react-native to 0.59.4, the latest update.
  • I also pleasantly realized that react-native-maps has released the official version of the update, so I was able to switch to that instead of using the github branch! Very nice 👌

Android, my nemesis

Then I went back to Android. Here's a summary of my issues:

  • I cannot launch the Android emulator with emulator -avd @x, but I can launch it from Android Studio. Not sure if that's related, but I did verify my path is set up correctly and whatnot.
  • Once the emulator is running, react-native run-android is successful. It launches on the device. However, it cannot connect to the dev server for some reason!
  • I try to open Dev Menu > Dev Settings on the emulator to check the port number, etc, but it crashes immediately on tapping the "dev settings" option from the menu!
  • However, it's a different story on a real device. It connects to the dev server and starts loading the bundle.
  • (I am able to open the dev menu > dev settings on a real device just fine.)
  • First time loading the bundle on my real device, and I get: Unable to resolve module react-timer-mixin``. Googling around, I didn't see any issues mentioning it. However, I saw that it was coming from native-base, so I decided to search for opened & closed issues matching `timer-mixin`. Turns out there was a recent PR which added it to their dependencies. Not sure why, but after updating `native-base` to the latest version, it loads on Android! Big win!

The Android Emulator

However, why won't it load on an emulator? I'm guessing it might be related to how it will open from Android studio but not from the CLI. The thing is, this was working for me on the previous version!

  • When I run emulator -avd android_emulator, I get this error: PANIC: Missing emulator engine program for 'x86' CPU.
  • So, I went into Android studio, deleted the emulator, made a new one on API 28 based on Pixel 2, and tried again. It still won't work from the CLI, but it launches just fine from Android Studio.
  • I'm still a bit confused about this situation. I went to the react-native docs again to check what their instructions are for the emulator. I opened the SDK manager and realized that I may not have everything installed. For Android 9.0 (Pie), I had installed (probably automatically when gradle was looking for the sdk update when I bumped it in my gradle config):
    • Android SDK Platform 28
    • Google Play Intel x86 Atom System Image
  • Now I also selected:
    • Sources for Android 28 (because I had this selected under the Android 8.1 config)
    • Google APIs Intel x86 Atom System Image
  • After applying the changes, I restarted the emulator, closed the packager, cleared the watchman and packager caches, and ran react-native run-android again.
    • I'm still getting react native version mismatch whenever I launch the app. JS version of 0.50.1 and native version of 0.59.4.
    • As soon as I click reload, it just goes to "could not connect to development server".
    • And the emulator still doesn't launch from the CLI.
  • I found the solution on an obscure xamarin thread lol. Wow, that took a while. It turns out that my path config pointed to tools/emulator instead of emulator/emulator. So I needed to change my path and re-source my shell in order to get the emulator launching again.
  • However, it still can't connect to the dev server, even after uninstalling the app and going through all that.
  • Ok, wow... I feel like an idiot. When initially performing the update manually, I did not add debug/AndroidManifest.xml. Why? I thought I wouldn't need it because I didn't have the debug folder already. Couldn't be more wrong. I really wish this error was more clear, though. Now it connects to the packager, loads, and the dev menu doesn't crash the app.

I would say that the big pain point is that we don't really know the implications of all the changes. I read through the changelog, but I didn't fully understand all the changes I would have to make to update the various Android dependencies. Additionally, the error messages are very poor. Obviously, it's most likely impossible to fix because, ya know, how do you know what's going to fail? But not one of the errors pointed me to a solution. Many were misleading, like the react-native version mismatch error. The reported error: both "react-native version mismatch" and "could not connect to dev server". The actual error: "Did not create debug/AndroidManifest.xml". I think that if I was able to read every PR and go through every change in a release, I might know this better. I feel that I do an ok job keeping up with new react-native news, but I don't have time to stay up-to-date with all of the android, ios, js, and react-native changes at once! I think one possibility would be a more clear changelog. Perhaps I'll try to contribute to that.

Anyways, thanks for reading! It seems that the update is finally finished. I think it took around 3-4 hours total. Not to bad compared to some previous updates ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.