How to Migrate Packages Used Across the Entire Project

0

As projects grow and time passes, there comes a moment when the foundational technology that was once the best choice is no longer optimal.@note Leaving this unchecked can lead to decreased development productivity and unpredictable issues.@note However, stable operation and technology migration are not easy tasks. In this article, we will introduce how the TUBA team at Toss solved these problems.

Toss’s All-Purpose Admin, TUBA

TUBA (Toss User Behavior Analyzer) is a data solution for Toss employees, including 22 sub-products such as A/B testing, messaging, and user segmentation. This product, used by employees from various departments, is an old project with several issues.

First Challenge: Extremely Long Build Times

The build speed of TUBA became very slow. Despite using yarn workspace to manage frontend sub-services and common modules, even minor modifications required rebuilding all services, increasing build time to 2 hours and 15 minutes.

The cause of the build speed issue was next 12, Module Federation, and the SSG build method. The TUBA team reviewed the necessity of next and started migrating from next to webpack. They created the next-polyfill package to implement alternative functionalities. This process reduced build time by approximately 86%.

Second Challenge: End-of-Life Packages

With the Recoil package reaching end-of-life, the TUBA team replaced it with Jotai, which is actively maintained and has minimal code impact. They used the ts-morph package to analyze the code and automatically convert Recoil functions to Jotai functions. This allowed them to migrate 900 files in about 100 seconds.

Conclusion

The TUBA team’s migration case will be highly beneficial for projects considering technical refactoring or removing deprecated packages. Consistent technical checks and updates are necessary for stable and efficient operation.

Leave a Reply