How to go about migrating a react repository with JSX to TSX

Given the pace at which frond end technology has been growing, it is easy to end up with ‘legacy’ code in our repositories. This is a retrospective or an account of my journey whilst trying to upgrade any organization’s repository and equip it with typescript superpowers. Technical debts are inevitable in the evolution of any code base and this is a popular use case given the raising popularity of typescript and its adoption among developers.

https://c.tenor.com/CT09jEK4vvkAAAAM/we-paid-off-the-debt-jesse-ridgway.gif

Assumptions/Things to know

• The code base had both legacy as well as code that was adequately typed. Migration refers to handling the legacy part of the code.
• React 17 was the version of the code base, which was built through create react app with react-scripts 4.0.0.
• The CI/CD pipeline would check for lint errors and typescript errors. But this was complicated as there were exhaustive uses of @ts-ignore

This document only outlines the processes which helped us safely type a complex project in a relatively short span. It is in no way a best practices guide, rather a retrospective for anyone else who is going to take up the same herculean task.

How did we go about this?

Step 1: Create a master branch for merging all the fixes by your peers

This means creating a branch against the primary branch to which all the contributors can merge their code. A sanity check can be run on this branch at the end of the migration activity and can be merged to master once all the regression bugs are addressed. This ensures that you don’t introduce regression bugs by merging pull requests often to the main branch and safeguards the users of your software from frequent disruptions.

It is very easy for a branch to quickly become stale especially when undertaking a tech debt of this scale. Ensure it is frequently updated with the primary master branch to avoid conflicts. It is also helpful to cut tags on your git branch to serve as backup.

Step 2: Divide and conquer

Create a master tracker of the files which need to be migrated against the assignees and the statuses. There could be specialists in areas of the code base and it makes sense for those specialists to pick up the files related to the migration. Take into account, the available bandwidth and make sure the assignments are justified.

Step 3: Eat, sleep, migrate, track.

Raise small peer requests to facilitate quick reviews of your code. Always stay on top of the open pull requests and ensure the master tracker stays in the most updated state. This helps your peers and the stakeholders with much-needed visibility on such massive tech debts.

Step 4: Test, test, and test.

Once all the files are successfully migrated and merged to the master branch for this activity, involve the quality assessment team to run a sanity check across the application. It also makes sense to leverage your peers and have them test their specialized features as part of community testing.

Step 5: Release it to production, and of course, PARTYYYY

Once you get the go-ahead from the quality assessment team, merge the master branch you created for this migration into the main branch. Monitor the environments for a couple of days to ensure a smooth user experience for the platform users.

For any suggestions, comments or just to say hi, do reach out at @sumo_dev_. Happy learning!