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 =)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 =)