CMS Monorepo Improvements: From Faster Builds to Bundle Optimization

Yeogiotae's integrated CMS operates over 10 Next.js apps in a single monorepo, with Spring Boot handling authentication and routing, and static files generated via Static Export then served through Thymeleaf templates. As the number of apps grew, each deployment took about 14 minutes, and even a single line change in the frontend required rebuilding all apps.

The bottleneck was the Next.js build. They cleaned up .dockerignore to reduce unnecessary file transfers and changed the setup to reuse previous build images like a cache. Next, they switched TurboRepo builds from sequential to parallel, running with --concurrency=3, with automatic retry at --concurrency=1 on failure, and used --continue so that if some apps failed, the rest of the builds would still proceed.

As a result, deployment time dropped from 14 minutes → 8 minutes, a reduction of about 43%, saving roughly 6 minutes per deployment. Pre-checking disk and memory also reduced failures caused by Docker image accumulation and resource shortages.

In the bundle optimization phase, they used an AI coding tool to analyze the entire monorepo structure and dependencies, first identifying lodash import patterns and side effects scattered across more than 20 files. Only 10 functions were actually in use — isEmpty, debounce, isEqual, orderBy, and others — and there were no patterns like chaining or mixin that would block converting to individual imports.

• For Lottie, they replaced the roughly 1.6MB full renderer bundle with lottie_light, cutting that chunk by about 75%.
• For lodash, they cleaned up full imports and named imports into individual imports, and also applied native alternatives such as Array.flat(), .filter(Boolean), and != null.
• By first addressing high-impact points such as Context files in shared packages, they reduced the lodash chunk in 3 representative apps from 299KB → 164KB, saving about 1.6MB overall.

However, Git diff-based build skipping, Turbo local cache, and per-app partial builds had limited effectiveness due to the JAR-integrated structure and Jenkins permission issues. Going forward, they plan to sequentially pursue unifying the TanStack Query version, unifying date-fns, and migrating from Recoil to Jotai, and in the long term aim for even shorter deployment times through an independent frontend deployment structure.