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

[simonbengtsson]

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]

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]

@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]

@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]

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]

@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]

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]

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

[joegoodall1]

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

[bondparkerbond]

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]

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]

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]

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]

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

[TheSavior]

Proposal: Per release upgrade discussion forum

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]

@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]

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]

Yup, the upgrade-helper would be the perfect place to have this. Maybe an issue per release that will then generate things like this -> react-native-community/upgrade-helper#47 (which are long-form explanations of the gotchas required that get linked in line in the webapp)

[TheSavior]

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.

[ollyde]

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]

The upgrade-helper never 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]

@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]

@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.

[ollyde]

@kneza23 Expo really?? For any project with at least a couple of dependencies, Expo is NEVER a choice.

[matt-oakes]

@sofiageo Please keep discussions civil and on topic.

---

@OllyDixon You're right that upgrading is a pain point of React Native. That is why this discussion was started. Some of the breaking changes have been avoidable, such as renaming of Cocoapod dependencies, but these are happening for good reasons.

Other parts of upgrading, such as needing to change Android build settings or Xcode project values, are because React Native is using "real" native tooling and needs to keep up with upgrades to those.

Because you're creating a native Android app, you need to use the latest versions of the Android SDK tools to get the latest SDK features. This does require some effort on your part as a developer. The same would be true if you were building just an Android app with Java/Kotlin.

Exactly the same is true of iOS apps with Swift/Obj-C. Developers using those build tools will need to go through very similar steps to you when upgrading their build tools.

Because React Native is using both of these build systems, you as a React Native developer have to deal with changes in both of these toolchains. This would be the same as if you had separate apps written in separate languages.

I know it's not ideal, but this is the cost of using a tool which works with the native build tools, rather than masking around them like Flutter or Cordova. When you are a React Native developer you need to invest some time to understand the tools you are using, which includes the native platform toolchain.

As I said before, the React Native team (which I don't speak for) know that upgrading is a pain point and this discussion was here to try to improve the situation. If you have specific feedback then I'm sure they'll be happy to listen to it 🙂

[ollyde]

@matt-oakes my main point is RN isn't the only tool that does this. In fact, Flutter, Xamrin, Unity + many others also use native build tools and we never see the same issues with updates. We used to have 7 Unity projects and 2 Xamarin projects and there were never upgrade issues. I understand that RN uses native views and native components but so do these frameworks, there's no excuse but poor architectural decision and yoyoing between toolsets + new toys and not mastering what we have.

@sofiageo thanks for the feedback, our partners and clients are private. Actually, the project you mentioned is an RN project that's recently been abandoned as it was too costly to maintain but the reviews have nothing to do with the app.

[RWOverdijk]

@OllyDixon What solution do you propose? What change would you make to solve this problem?

Because I agree, it is a problem. Would something like what expo does with unimodules be preferable? Because that works kind of great imo.

Update: Also 🍿

[ollyde]

@RWOverdijk slowdown! Stop jumping onto new tools every 2nd update that barely work. Perhaps bringing back some core features like 3-4 years ago would be a good idea, I know you guys shifted away from that but maybe having a decent navigator (like Flutter for example) would help. My 2 cents though.

[RWOverdijk]

@OllyDixon That won't solve the issue though, it will just make it less frequent.

To be honest it already became a lot better than it was, and I find upgrading to be quite simple when I do it manually. It only takes up about 20 minutes generally speaking...

Now with auto linking and pods being used it's even easier. So the main solution, I think, is maybe to stop touching core stuff in apps or move it to a more controlled environment like expo does with unimodules?

What are your thoughts?

[ollyde]

@RWOverdijk yes I agree with what you're saying they should stop touching core stuff and moving dependencies around, auto-linking was certainly a nice feature that should have been there day one :-)

Here's one example we had to upgrade. (Not even the most recent)
https://react-native-community.github.io/upgrade-helper/?from=0.58.4&to=0.62.2

Keep in mind lots of our core files were modified to support many of the plugins that don't support auto-linking or have a strange setup.

All-in-all the cost to our client was 2ish weeks of work. (We have to go through a full QA process across devices because we can't trust the updates anymore and we found many bugs)

We don't have the same process with other frameworks.

[kneza23]

@kneza23 Expo really?? For any project with at least a couple of dependencies, Expo is NEVER a choice.

Not a case anymore. When it all started maybe, but Expo now has a lots of additional dependencies. But as i said, if you really want to use RN right, you need to have some know how of native platforms and build systems. That is the whole point of RN, it is multi-platform but is still is native as it can be. If you were Android programmer or iOS programer, or took the time to learn at least basic stuff (especially regarding how each app is build) those changes in the upgrade helper would be piece of cake.

[ollyde]

@kneza23 I mentioned above that other frameworks also use native components + build tools and it's no issue.

[kneza23]

@RWOverdijk yes I agree with what you're saying they should stop touching core stuff and moving dependencies around, auto-linking was certainly a nice feature that should have been there day one :-)

Here's one example we had to upgrade. (Not even the most recent)
https://react-native-community.github.io/upgrade-helper/?from=0.58.4&to=0.62.2

Keep in mind lots of our core files were modified to support many of the plugins that don't support auto-linking or have a strange setup.

All-in-all the cost to our client was 2ish weeks of work. (We have to go through a full QA process across devices because we can't trust the updates anymore and we found many bugs)

We don't have the same process with other frameworks.

Good idea is to update more frequently and then it would not be that much of a difference as in your example.

[kneza23]

@OllyDixon which ones?

[RWOverdijk]

@kneza23 Also true. But it would be nice if that didn't matter too much, right? I've worked on multiple projects at the same time and they don't all have continuous development on them. So when upgrading it'd be nice if it just... worked.

I'm just trying to give this a productive spin, it feels a bit angry while all I see is opportunity to improve. 😄

[cpojer]

This issue is not the right place for the discussion that was sparked today. I will lock the issue.