Closed cpojer closed 4 years ago
xzilja
commented
5 years ago 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
commented
5 years ago 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 ❤️.)
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.
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.
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.
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
commented
5 years ago 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:
package.jsonnpm install or similarI 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
commented
5 years ago 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:
react-native-git-upgrade), another popular article about upgrading I used a lot is this oneAnd, personal experience:
.xcodeproj is hellish to work with - using pods has helped a ton with it (related proposal)
fungilation
commented
5 years ago 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.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:
react-native-git-upgrade which seems permanently borked.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: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)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
commented
5 years ago 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
commented
5 years ago 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 https://github.com/facebook/react-native/issues/19859 and https://github.com/facebook/react-native/issues/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
commented
5 years ago 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
commented
5 years ago Just wanted to add that for us upgrades has been fairly smooth. Basically:
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 (https://github.com/facebook/react-native/issues/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.
elicwhite
commented
5 years ago 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:
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
commented
5 years ago @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
commented
5 years ago @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
commented
5 years ago 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.
elicwhite
commented
5 years ago @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
commented
5 years ago 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
commented
5 years ago A better updated one than rn-diff is https://github.com/pvinis/rn-diff-purge
joegoodall1
commented
5 years ago Thanks, @fungilation, wasn't aware of this.
bondparkerbond
commented
5 years ago 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:
zinoviev
commented
5 years ago Just sharing the last time(nov 18) upgrade attempt:
Oh and not to forget - we are suffering from https://github.com/facebook/react-native/issues/19569 and https://github.com/facebook/react-native/issues/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
commented
5 years ago 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
commented
5 years ago 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?
dani-mp
commented
5 years ago @pvinis would you main explaining the difference between rn-diff and rn-diff-purge?
pvinis
commented
5 years ago Of course.
The rn-diff repo has an app that was made with RN 0.27 or so, and it has been using the rn-upgrade and git-upgrade to keep it up to date. After the update, it creates the diff.
The rn-diff-purge repo inits an app every time there is a new react native version. After that, it creates a diff from the app from the previous version.
The purge way has a few improvements over the older way.
No more depending and waiting for the git-upgrade tool to support the newly released version. IF we wanted, we could even generate diffs for every rc release too, with git-upgrade would not support most of the time anyway.
Diffing from a clean project has the advantage of getting the latest changes from the RN project template. Take the following diffs from both repos, for RN 0.48.4->0.49.0.
https://github.com/ncuillery/rn-diff/compare/rn-0.48.4...rn-0.49.0
https://github.com/pvinis/rn-diff-purge/compare/version/0.48.4...version/0.49.0
Notice the files index.android.js and index.ios.js being removed, and index.js being created in the purge repo. That was the version where the project template unified these files.
In the old repo, there is no change in any of the three files above. The reason is that, of course by not changing these files, the project will still work. But without having the knowledge that these files are changed in the project template, you might have a harder time later. People will start using the Platform API more for example, and when after a few versions there is something deprecated, you will need to take a nice long week to fix all the incompatibilities before updating to the new shiny version you want, because it has a cool new feature, but breaks your project.
With the purge diff, now you know that these files are merged into one. If you care about it, you merge your project's files too. If you don't mind or prefer keeping them separate, go ahead and do that. But at least now you are aware of the change and make an informed decision.
The way I use this repo is I see the diff, and take a few minutes to manually do the changes in my projects. I am not using the patch way since each project has its own unique ways, but that's just my choice. I use it to get a diff immediately after a new RN version is released, and to see a complete picture of what changed that I care about. I am adding the RN version diffs for the latest versions like https://github.com/facebook/react-native/compare/v0.57.7...v0.57.8, because some people care about what changed internally too.
Let me know if that makes sense, if it helped, and if you would like further explanation. :)
dani-mp
commented
5 years ago @pvinis that makes a lot of sense, thanks for the detailed explanation. You rock.
export-mike
commented
5 years ago aside from gradle related changes what actually changes that frequently?
I've tried to run react-native-git-upgrade a few times, the diff is confusing. Feels to me that maybe we could have a blog post announcing changes to the "BUILD" changes to files within android and ios directories.
I've been able to upgrade fine by just upgrading using yarn.
yarn add react-native :D
keelius
commented
5 years ago Most of the problems I ran into stemmed from the native modules I used in my project. It quickly got to the point where I had to document the process of rebuilding the entire project and its settings so I could upgrade. I would only upgrade every other release as this would take a few hours if everything went smoothly.
Most of the time this wasn't the case and I would spend several days digging through random github issues to figure out why I was getting ambiguous failed build messages from either platform. Normally, this stemmed from either react-native-maps and react-native-fbsdk. react-native-fbsdk was giving me heartburn almost from day one and then when I included react-native-maps it got even worse because at that point I was using CocoaPods so I could build my app remotely. FB's recommendation of linking the necessary framework files to use FBSDK to my Documents folder just didn't cut it. Maybe I was doing it wrong, but I had to enable use_frameworks for one of the FB frameworks to work. This then broke stuff for react-native-maps. Most times I had to stay on an older version of RN that I could just get to work at all when react-native-fbsdk was installed.
I'll admit that this was very specific to my project due to the requirements, but this constant battle every time I wanted to upgrade was no fun. It's probably 80% of why I will avoid RN for future mobile apps. I still try to stay up on what's going on with the project, hoping that these kind of problems will get sorted out. I just don't have the time, patience or intelligence to constantly solve all the issues building a non-trivial mobile app in RN as the sole developer.
cpojer
commented
5 years ago We are still gathering context about how to improve the situation. One thing that would help greatly is if you had concrete reproducible examples where upgrading went wrong.
Does anyone have either:
At Facebook, we never have to upgrade React Native as we are always running master. We'd like to feel the pain so we can think about real solutions.
pvinis
commented
5 years ago @cpojer you can take https://github.com/ncuillery/rn-diff and try to upgrade from 0.57.2 to anything higher.
This should be the easiest problematic case since the app is just a react-native init project, and upgrading has been a problem since that version. There where problems before too, but I don't remember specifics.
SaraChicaD
commented
5 years ago 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:
58.6 but then 59 came out while we were still trying to get that to work)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:
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:
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
pvinis
commented
5 years ago @sarachicad hello. I have 2 questions for you because I'm curious.
SaraChicaD
commented
5 years ago @pvinis
55.3 despite the upgrade tools and release notes, we couldn't get it to workcpojer
commented
5 years ago @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
commented
5 years ago @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
commented
5 years ago 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
commented
5 years ago so:
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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago @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:
noahtallen
commented
5 years ago 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:
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!
yarn global add react-native-cli to make sure I had all the latest version with the new upgrade tool.react-native upgrade and immediately got this:
react-native-cli was last published two years ago. Oof!@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.yarn global remove react-native-cli and then tried again. Seems to be using the latest upgrade tool now!
Most of the files are upgraded but you will need to deal with some conflicts manually
package.json first."babel-core": "^7.0.0-bridge.0"; I hope it doesn't break anything!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."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 ../../../..",
react-native-svg. However, it could also be an issue with the transpiler. I'll try updating react-native-svg first.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.
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.
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-mapsERROR: 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.
<img width="344" alt="Screen Shot 2019-04-07 at 11 02 29 PM" src="https://user-images.githubusercontent.com/6265975/55696037-3c62a480-5989-11e9-931c-60fb76888bf9.png">
- *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. :) 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
Then I went back to Android. Here's a summary of my issues:
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.react-native run-android is successful. It launches on the device. However, it cannot connect to the dev server for some reason!Unable to resolve modulereact-timer-mixin`. Googling around, I didn't see any issues mentioning it. However, I saw that it was coming fromnative-base, so I decided to search for opened & closed issues matchingtimer-mixin. Turns out there was a recent PR which added it to their dependencies. Not sure why, but after updatingnative-base` to the latest version, it loads on Android! Big win!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!
emulator -avd android_emulator, I get this error: PANIC: Missing emulator engine program for 'x86' CPU.react-native run-android again.
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.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 ;)
elicwhite
commented
5 years ago I’ve heard from a lot of people that when upgrading, they frequently run into issues that require searching on Google and GitHub or trying to find medium articles, but most often just figuring out the fix for themselves, duplicating the work and investigation others did for their apps.
I’ve been wondering if having a centralized, recommended discussion area for each release and the problems people run into would be helpful.
For example, maybe for each release we link to somewhere (Stack Overflow tag, Reddit thread, GitHub label, etc) where we recommend people post about the issues they’ve found when upgrading to that release. Unlike GitHub issues on the main repo, these aren’t necessarily about bugs, they are about “oh, I had to flip this config in my Xcode project”, or “I'm getting this weird error, I didn’t notice this breaking change in an API”.
That link can be included in the release notes, upgrade helper, etc. In the short term I could imagine this helping people going through upgrades track down their issues quicker while building community at the same time instead of upgrading their projects being a very isolating experience. In the long term, this will help us get a better picture of the kinds of issues people run into when doing upgrades in order for us to make the process better, know which documentation we are missing, etc.
lucasbento
commented
5 years ago @TheSavior I would love to include something like that on the upgrade-helper, I have been meaning to have a Troubleshooting section where people could post their "gotchas", I'm definitely open for discussing more solutions around this topic 🙂
pvinis
commented
5 years ago Also, the results of conversations/solutions could be included as notes on the diffs in the helper, so the people afterward can be helped without searching.
kelset
commented
5 years ago Yup, the upgrade-helper would be the perfect place to have this. Maybe an issue per release that will then generate things like this -> https://github.com/react-native-community/upgrade-helper/issues/47 (which are long-form explanations of the gotchas required that get linked in line in the webapp)
elicwhite
commented
5 years ago I've heard some feedback from a fair amount of people on the proposal for a community upgrade support forum a couple of comments up.
I'd like to make some more concrete recommendations.
I propose that we create a new repo in react-native-community called upgrade-support. People could post issues in this repo, including the result of running react-native info. A bot would apply two labels for each issue. For an issue reported on 0.61.0, it would apply 0.61 (to be able to see issues for any patch release) and 0.61.0 (to filter to a specific patch).
The upgrade-helper for each release will link to the issues with the label specific to that patch version.
Ideally the issues in the repo would be focused on one specific problem, making it easy to scan for related issues.
Alilife737
commented
4 years ago Android resource linking failed AAPT: C:\Users\ali_b\Desktop\SpeedyCar\app\build\intermediates\incremental\mergeDebugResources\merged.dir\values\values.xml:113: error: resource drawable/btn (aka com.sayaratidemo.Highspeeddriving:drawable/btn) not found. error: failed linking references.
ollyde
commented
4 years ago The upgrade-helper never ever works for any person I've talked to using RN unless it's a super basic project. But the real question is, why should we need such a tool, why are there so many breaking changes with each update?
People are leaving RN in droves because of the immature updates pushed out. For example, recently Flipper was added, dependencies were moved around again for 100th time, every update completely breaks the platform and introduces bugs, some of the changes are just WTF? Are you guys serious?
Fortunately we've been able to delete all our RN projects in the company and migrate to Flutter after 2 years. We are yet to see a single Platform bug with Flutter, and upgrading has never been an issue, literally spend no time on it, much better LTS especially for serious companies.
Compare that to RN where 50-60% of our time was spent trying to get it to work across the devices.. the same feeling across all the ex-RN teams. Not to mention the navigation libraries offered are still garbage in 2020. Debugging on Android? Haha forget about it, I could list many things but you get the point.
MoOx
commented
4 years ago The
upgrade-helpernever ever works for any person I've talked to using RN unless it's a super basic project
Sorry but I have a complex white-label app (with around 20 clients & declinations etc) with various native code parts for iOS & android: this tool is literally a life saver & I don't see a simpler solution.
Before this tool, yeah this was hard (hello react-native-git-upgrade), but this tool is literally super simple to use. It seems you are talking like you never used it.
Applying patches by hand might look stupid in 2020. But since you may have modified a lot some natives files, it's imo the easiest & fastest way to upgrade safely an RN app. And if you find RN to be too complex to handle, you have Expo that might help a lot, as upgrade process have nothing to do with upgrading a raw RN project.
(Reminder: Flutter doesn't produce a real native app as all "styles" can be used on any platform (eg: iOS components have been recreated https://github.com/flutter/flutter/tree/master/packages/flutter/lib/src/cupertino))
ollyde
commented
4 years ago @MoOx I understand but we used to have more than 14 completely different applications written with RN some with millions of customers and various levels of complexities and all of them were a pain to upgrade / tons of bugs / tons of issues. Also, I see the endless proposals and changes in each version has got me questioning if React-native really knows what/where is it going, have you tried Flutter? It will change your mind on RN completely, none of these garbage changes each update, also native ui code is supported and it never breaks.
kneza23
commented
4 years ago @MoOx I understand but we used to have more than 14 completely different applications written with RN some with millions of customers and various levels of complexities and all of them were a pain to upgrade / tons of bugs / tons of issues. Also, I see the endless proposals and changes in each version has got me questioning if React-native really knows what/where is it going, have you tried Flutter? It will change your mind on RN completely, none of these garbage changes each update, also native ui code is supported and it never breaks.
Dude, RN is native, Flutter is not at least not in the same way as RN. They are completely different worlds and approaches. like @MoOxs said, Expo can be used by the devs who do not have Android/iOS experience.
This issue is part of What do you dislike about React Native?.
The top voted answer was that upgrading React Native is painful, see https://github.com/react-native-community/discussions-and-proposals/issues/64#issuecomment-444775432.
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!