Web应用核心与定制模块拆分方案优化咨询

针对你当前核心仓库+客户定制仓库的场景，以下几个方案比自行开发Vite插件合并文件更规范、易维护：

一、基于独立npm包的核心依赖方案 #

将公共核心应用封装成独立的npm包（比如@your-org/core-frontend），每个客户仓库作为独立项目依赖该核心包，通过模块替换/别名优先级实现客户代码覆盖核心代码：

实现要点： #

1. 核心包封装：

   • 把核心的组件、路由、状态管理、基础配置封装成可扩展的npm包，暴露初始化入口（如createCoreApp）和可扩展接口（如组件替换钩子、配置注入）。
   • 核心包的目录结构清晰划分，比如src/components、src/views、src/config等，方便客户针对性替换。

2. 客户仓库配置：

   • 客户仓库仅维护定制化的组件、页面、配置文件，通过Vite的别名配置，让客户本地文件优先级高于核心包：

     // vite.config.js
     import { defineConfig } from 'vite'
     import path from 'path'
     
     export default defineConfig({
       resolve: {
         alias: [
           // 优先加载客户本地组件，不存在则 fallback 到核心包
           { find: '@core/components', replacement: path.resolve(__dirname, './src/components') },
           { find: '@core/components', replacement: '@your-org/core-frontend/src/components' },
           // 同理处理页面、工具函数等目录
           { find: '@core/views', replacement: path.resolve(__dirname, './src/views') },
           { find: '@core/views', replacement: '@your-org/core-frontend/src/views' }
         ]
       }
     })
     

3. 扩展机制：

   • 核心包提供配置注入能力，客户仓库通过配置文件传递定制化参数（如新增路由、自定义主题、功能开关）：

     // 客户仓库入口 main.js
     import { createCoreApp } from '@your-org/core-frontend'
     import customConfig from './custom.config.js'
     
     const app = createCoreApp({
       ...customConfig,
       // 核心默认配置
     })
     app.mount('#app')
     

优势： #

• 依赖管理规范，核心包更新通过npm版本迭代，客户仓库只需升级依赖即可同步核心更新；
• 客户仓库仅存定制代码，结构极简，无需维护复杂的合并逻辑；
• 完全复用Vite原生模块解析能力，避免自定义插件的维护成本。

二、基于配置驱动的动态扩展方案 #

如果客户定制内容以组件替换、少量新增页面为主，可以让核心应用内置配置驱动的扩展机制，客户仓库仅需维护配置文件和定制资源：

实现要点： #

1. 核心应用设计：

   • 核心应用启动时，自动读取客户目录下的配置文件，根据配置动态注册组件、路由：

     // 核心应用的扩展加载逻辑（Vue示例）
     import { defineAsyncComponent } from 'vue'
     import router from './router'
     
     // 自动导入客户定制组件
     const customComponents = import.meta.glob('../customer/src/components/**/*.vue')
     for (const path in customComponents) {
       const componentName = path.split('/').pop().replace('.vue', '')
       app.component(componentName, defineAsyncComponent(customComponents[path]))
     }
     
     // 加载客户新增路由
     import customRoutes from '../customer/src/routes.js'
     customRoutes.forEach(route => router.addRoute(route))
     

2. 客户仓库结构：

   • 客户仓库仅需包含：定制组件目录、新增路由文件、自定义样式；
   • 核心应用通过Vite配置将客户目录加入源码扫描范围：

     // vite.config.js
     export default defineConfig({
       resolve: {
         alias: {
           '@customer': path.resolve(__dirname, './customer')
         }
       },
       css: {
         preprocessorOptions: {
           scss: {
             additionalData: `@import "@customer/src/styles/custom.scss";`
           }
         }
       }
     })
     

优势： #

• 客户仓库的维护成本极低，无需关注构建逻辑；
• 核心应用统一管理扩展逻辑，避免每个客户仓库重复配置；
• 动态加载机制灵活，支持按需加载定制内容。

三、基于微前端的隔离式扩展方案 #

如果客户定制需求差异极大（甚至需要不同技术栈），可以用微前端架构将核心应用作为基座，客户定制内容作为独立微应用集成：

实现要点： #

1. 核心基座搭建：

   • 核心应用作为主基座，负责公共导航、状态管理、权限控制等公共能力，通过微前端框架（如Module Federation、qiankun）加载客户微应用。

2. 客户微应用开发：

   • 每个客户仓库对应一个微应用，独立开发、构建、部署；
   • 核心基座通过配置动态加载对应客户的微应用，比如根据域名、请求参数判断：

     // 核心基座加载微应用逻辑（qiankun示例）
     import { registerMicroApps, start } from 'qiankun'
     
     const customerApps = [
       {
         name: 'customer-a',
         entry: '//customer-a.your-domain.com',
         container: '#micro-app-container',
         activeRule: '/customer-a'
       },
       {
         name: 'customer-b',
         entry: '//customer-b.your-domain.com',
         container: '#micro-app-container',
         activeRule: '/customer-b'
       }
     ]
     
     registerMicroApps(customerApps)
     start()
     

优势： #

• 核心与客户代码完全隔离，互不影响，核心更新无需同步到客户仓库；
• 客户微应用可自主选择技术栈，适配特殊定制需求；
• 支持独立部署，客户定制内容更新无需重新构建核心应用。

四、基于Git子模块的代码复用方案 #

如果需要深度定制（比如修改核心源码的部分逻辑），可以用Git子模块将核心仓库嵌入客户仓库，同时保持核心代码的独立维护：

实现要点： #

1. 核心仓库作为子模块：

   • 在客户仓库中添加核心仓库为子模块：

     git submodule add https://github.com/your-org/core-frontend.git core
     

2. 构建配置：

   • 在Vite配置中同时指定核心和客户目录为源码目录，通过别名设置客户文件优先级：

     // vite.config.js
     export default defineConfig({
       resolve: {
         alias: {
           '@': path.resolve(__dirname, './src'),
           '@core': path.resolve(__dirname, './core/src')
         }
       },
       optimizeDeps: {
         include: ['@core/**/*']
       }
     })
     

3. 核心代码更新：

   • 客户仓库可通过git submodule update --remote同步核心仓库的最新代码，同时保留本地定制修改。

优势： #

• 支持深度定制核心代码，适合需求特殊的客户；
• 核心代码的版本管理清晰，可灵活选择同步核心的特定版本。

内容的提问来源于stack exchange，提问作者lethargie