Light Weight Migration of Legacy React Native Project and Library
Written by Sandeep Suryabali Rajbhar
Solution ArchitectReact native is the most dynamic and widely used cross-platform app development framework for iOS and Android. The react native app developer use lot of third-party plugin/packages. The dynamic nature of React Native platform come with side effect when it comes to the legacy library update and maintenance. In 2019, when both Android and IOS announced the deprecation of the 32bit app, especially React Native developers faced challenges for the upgrade due to using a lot of third-party plugins/packages. The same situation comes in the future when we keep using the legacy library.
While working on the project, a lot of developers avoid this consequence in day-to-day work and end up having a lot of deprecated libraries that work on the older version that is not updated to new ones. This creates an issue when it comes to using new APIs and features of plugins/packages.
Although there is no ideal way to upgrade react-native, many developers still use "react-native upgrade" or "react-native upgrade --legacy" to upgrade the library. It is ok with a small project, but it can create a big mess in life and big applications. If you are using an agile methodology, you will be in big trouble as we usually release a build daily, and suddenly, you will start getting a lot of bugs and crashes. It will be very difficult even for a developer to track the issue.
This article has real-time instances of migration from the legacy app library without hampering the current and future PI. We have used the phase-wise upgrade strategy to upgrade the library, but that also required a lot of analysis and divided the upgrade into phases according to many parameters, which we will see below step by step.
Step 1: Get a List of all third-party libraries in the project:
We need to list down all the third-party libraries used in the application. You can go to the package.json file to get all the lib from the dependencies section.
Step 2: Current version vs. latest version vs. the n-1 version of the third-party library in the project
You can get the latest version from the code project and go to the NPM packages document to get the latest version and n-1 version. We will check this parameter to get the most stable version of that library.
Step 3: Downloads of the latest version vs. the n-1 version of the third-party library in the project
Go to the NPM packages document to get the number of downloads of the latest version vs. the n-1 version, with which we will decide the stability of the version. We will only be going to mention and compare between "current version vs. latest version" or "n-1 version vs. latest version" or "current version vs. n-1 version"
Step 4: Forked Library
In the project, we often do not want to upgrade the forked lib and still want to continue using the same as the new one might not be much stable, or we have manually done some changes. So "react-native upgrade" or "react-native upgrade --legacy" can create a mess for you, so this is a very important parameter during analysis.
Step 5: Vulnerability issue
The vulnerability of third-party libraries is another concern for many clients, so we can also check that with the "npm run audit" cmd to get a list
Step 6: Need to Upgrade?
With the above parameter, we can analyze and decide whether we need an upgrade.
Step 7: Phase-wise division of the library
We have then divided all the lib according to phases and tested accordingly by finding the most affected section of the app.
- Phase 1: (Lib related to RN, Security scan report)
- Phase 2: (Lib related to redux, data)
- Phase 3: (lib related to UI and Navigation)
- Phase 4: (lib related to forked)
- Phase 5: (other)
In each phase, we had to ensure that we will keep testing the most affected feature and functionality related to the library we upgraded
Step 8: Risk Analysis
- Prerequisite: Updated version of XCode and android studio (Gardle if needed)
- Impacted feature related to Firebase Analytics, Crashlytics, Push notification, File upload
- Risk:
- It might be some of the features will not work and need an update on another phase lib.
- Need to change API method signature related to lib in case of any change
- Check the change log of third-party lib
- Sanity testing for the whole app. As base lib getting change related to react native app development.
In each phase, we had to ensure that we will keep testing the most affected feature and functionality related to the library we upgraded
Step 9: Future, how to track upgrade of dependencies lib
Configuring dependent security updates by using a plugin like "Renovate Me." More detail: https://marketplace.visualstudio.com/items?itemName=jyc.vsts-extensions-renovate-me
Feature:
- Receive automated Pull Requests whenever dependencies need updating
- Define schedules to avoid unnecessary noise in projects
- Relevant package files are discovered automatically
Challenges faced during lib update
Phase-wise update helps us to do smooth migration of library without too much mess and clean testing after each phase in restrictions. However, we have faced some challenges mentioned below,
- During the upgrade of react-navigation lib, there were so many API changes. We need to scan through the whole app code, search for removed methods, and use alternate methods like the getParam method.
- SwitchNavigator was removed from react-navigation, and we had to find an alternate way of making navigation for those screens.
Lightweight Migrations in Core
An application that develops and gains features also gains new requirements. In this blog post we have shown how we can differ from the migration approach and how we can make things easier the process and significantly cut down the amount of work required to perform a successful migration. For more information, you can reach out to us at [email protected] or visit www.royalcyber.com.
