Transforming a Massive Vue Frontend into a Scalable Monorepo: Lessons & Strategies

1. Introduction to Xingyun 2.0

In the Xingyun 2.0 era, a once‑ordinary business project grew rapidly into an ecosystem of dozens of sub‑applications, each offering diverse product features. Built on Vue, the platform can load non‑Vue apps while providing a shared Vue instance, router, Vuex, global component library, and axios instance for dependent sub‑apps.

2. Early Architectural Dilemmas

Looking back at the original front‑end architecture reveals several critical issues:

1. Chaotic code structure – Although a /modules folder existed, component imports crossed module boundaries without clear layering, creating tangled dependencies.

2. Business entanglement – The monolith handled platform foundations and various business domains, leading to high coupling and risky domino‑effect changes.

3. Full‑bundle builds – Frequent releases (every 2‑3 weeks) triggered full‑project builds, causing white‑screen failures.

4. Commercialization challenges – Unclear business boundaries made custom client requests labor‑intensive and error‑prone.

5. Internal iteration gaps – Migrating new features across multiple Vue versions and TypeScript upgrades introduced compatibility hurdles.

6. Bloated static resources – Shared dependencies could not be easily stripped, inflating bundle size.

7. Deprecated components – Old, unused components lingered in the codebase, increasing maintenance complexity.

8. Atomic style chaos – Inconsistent use of atomic CSS (WindiCSS) caused style duplication and larger builds.

9. New business expansion difficulty – Adding new features risked breaking UI consistency and extending build times.

10. Single build tool limitation – Relying solely on Vue CLI led to slow builds as the codebase grew.

3. Struggle and Determination

Despite the massive codebase (over 100k lines) and limited resources, the team persisted, recognizing that solving the right problems was essential for sustainable growth.

Opportunity to achieve inner‑outer same‑origin integration.

4. The “Inner‑Outer Same‑Origin” Breakthrough

The team defined a “Kill‑Switch Plan” focusing on:

Module isolation – separating platform and business code.

Lean builds – only building the changed sub‑app.

Code cleanup – removing dead components and redundant code.

Atomic style standardization – consolidating to a single Tailwind CSS setup.

Enhanced extensibility – layered architecture respecting the open‑closed principle.

Gradual migration using the “Kill‑Switch” pattern (progressively replace old modules with new ones).

5. Architectural Evolution Roadmap

Stage 1: Monorepo Preparation (pnpm workspace)

Create directory structure.

Introduce tools: pnpm workspace, Nx.

Update CI/CD configuration.

Stage 2: Monorepo Implementation

Separate business modules into independent apps under apps/ (admin, ai‑assistant, jacp, open, platform).

Extract shared packages (common, common‑service, components, tailwind‑config, utils, xingyun‑elements).

Migrate from WindiCSS to Tailwind CSS.

Stage 3: Automated Build Process

Use Vue CLI/Vite for business apps and Vite/tsup for shared packages.

Optimize build pipeline: incremental builds, dependency pre‑building, publishing scripts.

6. Post‑Refactor Engineering Landscape

New Dependency Diagram

Project Structure Overview

The new layout includes:

apps/ : independent applications (admin, ai‑assistant, jacp, open, platform).

packages/ : reusable modules (common, common‑service, components, tailwind‑config, utils, xingyun‑elements).

Technology Stack

Front‑end framework: Vue.js

Monorepo tool: Nx

Package manager: pnpm

UI: Custom component library + Tailwind CSS

Build tools: Vue CLI / Vite

Design Principles

Modularity – high cohesion, low coupling.

Micro‑frontend – independent deployment.

Component‑driven development.

Theming with Tailwind CSS.

Incremental builds via Nx.

TypeScript & ESLint for code quality.

Module Responsibilities

apps/ modules each have their own routing, state, and UI, sharing code from packages/. Examples:

jacp – core collaboration domain.

platform – host for loading sub‑apps.

admin – system management.

open – open platform and app store.

ai‑assistant – AI chat interface.

packages/ provide shared utilities and components, such as common (shared Vue environment), common‑service (API wrappers), components (UI library), tailwind‑config, utils, and xingyun‑elements (web components).

Development Optimizations

Partial migration to Vite for faster dev servers.

Cache usage to speed up startup and builds.

Parallel processing in build configs.

Webpack hard‑cache for stable packages.

Micro‑frontend tooling to simplify sub‑app debugging.

Cloud Build & Caching Strategies

Code splitting with async components and dynamic imports.

Webpack file‑level cache combined with Nx incremental builds.

Cache layers in deployment images to accelerate builds.

Extensibility

Add new apps by creating a folder under apps/ and configuring Nx.

Add new shared modules under packages/ and import where needed.

Extend existing modules following the open‑closed principle.

7. Summary

The Xingyun front‑end evolved from a monolithic Vue app to a micro‑frontend monorepo, addressing issues such as tangled code, heavy builds, unclear business boundaries, and style chaos. By adopting the “inner‑outer same‑origin” plan, the team achieved modularization, lean builds, code cleanup, unified styling, and improved extensibility, resulting in a lightweight, maintainable, and scalable front‑end architecture.