What're your strategies to upgrade a React app that's in production?

I moved to a new company as a full-time frontend dev, the company has a React app that works as a dashboard where their users can create/manage automated financial-workflows, now, the current codebase is "IMO" pretty messy, think of the following:

1. Some parts of the app were written in JS and others are written in TS.
2. There're no unit tests what so ever!
3. I'm not sure if this one is common but the backend guys are contributing to the frontend app.
4. There's no unified code style across the codebase, every one is applying their style.
5. The app is using multiple solutions for the same problem, for instance, they're using styled-components, antd, and mat-ui all at the same time.

that was to give you a hint about what the codebase looks like.

What I'm asking is this, if you're in my position, what would be your strategies/plans to deal with this situation?

Comments

[Gleb Irovich]

Hey Ahmed, congrats with your new position! Could you elaborate on the end goal you want to achieve. What do you mean by “upgrading React”? Upgrading a library? Unifying application codebase?

[Ahmed Kamal]

Hi Gleb, what I'm thinking of is this:

• the codebase should be migrated from JS to TS.
• the codebase should be covered by unit tests.
• we should drop the unused libs/code and upgrade the outdated ones.
• and finally, we should have some sort of "paradigm" to follow to make our lives easier as a team.

So, my questions are;
Am I concerned about the right things or I'm just overreacting to a new codebase?
Are my thoughts above valid?
and if so, How to achieve them?

Note: by "How to achieve them?" I mean what're the techniques to follow to apply these changes while working on fixing bugs, adding new features at the same time since the app is already in production.

TL;DR
The main idea of this post is to brainstorm with the community on how different devs deal with this kind of situation if that makes sense!

[Gleb Irovich]

Hey Ahmed,

I think you are concerned about the right stuff. From my experience migration to a newer stack is rather a marathon than a sprint. So prepare yourself for the long run. Let's skip all the steps where you have to justify your changes and assume, that you got a green light. Here is some thought I have.
-> Migration to typescript can be relatively gentle. You don't have to make your app typed overnight. If you have a custom webpack, introduce typescript and allow js. Alternatively, convert all the files to ts extensions, but keep typescript flags loose. Migrate pieces of code whenever you touch them, slowly your codebase will move to the new rails.
-> Testing is always great to have, however, usually it's rather a cultural problem than technical. Your team must agree to write more tests (if they currently don't) and you should decide on the guidelines. When do you use unit / components / e2e tests? What technologies / libs to use?
Making testing part of the DoD (definition of done) is probably the most challenging part, because, for some reasons on the frontend tests are often being taken not serious enough.
-> updating libs is a nice idea, but it requires some planning, especially if some libs must be replaced and code refactored.
-> to decide on the guidelines we are currently using a weekly web tech exchange. If anyone from the team has to come up with some opinionated solutions, he simply adds it to the "inbox" and we discuss it. It helps to keep discussions very close to the use-case. Decisions are written down in CONTRIBUTE.md and serve as a reference should anyone have the same question. Some guidelines can be also enforced with eslint rules.

TL;DR
I think you are on the right track. Have a plan and approach migration in smaller steps. Migration is always a stress for a team since people don't like changes, so communicate well and make sure you are aligned with your colleagues.
Good luck =)