element-plus（Vue 3）构建分析

这一篇不是在复述 element-plus 的功能列表，而是把它当成一个真实的大型 Vue 3 组件库案例来观察：

一个成熟组件库，通常会怎样组织源码、构建流程、文档、测试与发布能力？

element-plus 很适合作为案例，因为它不是一个“只有组件代码”的仓库，而是一个完整的组件库工程。

先看这个案例为什么值得分析

当你自己开始做组件库时，很容易只盯着：

• 组件怎么写
• 样式怎么写
• 打包怎么配

但一旦规模上来，真正困难的往往变成：

• 怎么拆包
• 怎么管理构建脚本
• 怎么维护文档站和 playground
• 怎么处理类型、SSR、测试、发布

而这些，正是 element-plus 这种成熟项目最值得借鉴的部分。

运行环境

• Node.js LTS（22）
• corepack@latest 用于自动安装和切换 packageManager

前置运行步骤

1. fork element-plus 到自己的仓库
2. clone 到本地
3. 执行 pnpm i

这一步的意义不只是把项目跑起来，更重要的是让你能边看仓库结构边对照实际构建行为。

项目分析

element-plus 主体是一个 monorepo。

从工程角度看，这已经说明了几件事：

• 它不是单包项目
• 文档、组件源码、内部工具、测试、类型和发布能力被拆到了不同位置
• 构建不是“一条 vite build”就能解决的，而是更复杂的任务编排

文档里常见的概括是：

• 使用 rollup 处理核心构建输出
• 使用 gulp 进行任务编排

你可以把它理解成：

• rollup 更偏产物打包
• gulp 更偏流程串联和任务组织

目录分析

这里只列一些核心目录：

dist # 构建产物
docs # vitepress 文档网站
internal # 内部包与构建相关能力
packages # 组件与源码主目录
patches # 补丁目录
play # playground
scripts # 直接执行脚本
ssr-testing # SSR 测试
typings # dts / 类型相关

只看这一层目录，你就已经能得到一个很重要的结论：

成熟组件库的仓库结构，通常不是围绕“组件文件”组织，而是围绕“完整交付链路”组织。

也就是说，它会同时考虑：

• 源码
• 构建
• 文档
• 调试
• 测试
• 类型
• 产物

packages 为什么重要

packages 通常是最接近“业务上理解组件库”的地方。

这里一般会包含：

• 组件源码
• 组件入口
• 工具函数
• 组件导出关系

如果你是第一次分析大型组件库，最值得看的通常不是某一个按钮组件本身，而是：

1. 组件目录如何分层
2. 对外入口如何组织
3. 组件、样式、类型之间如何配合

换句话说，packages 回答的是：

这个库到底怎样从很多零散组件，组织成一个可以被外界消费的公共接口？

internal 为什么值得重点看

对中小型组件库来说，很多构建逻辑可能直接写在根目录脚本里。

但对 element-plus 这种规模来说，内部构建能力本身就值得被模块化。

所以 internal 这类目录通常意味着：

• 构建工具链不再只是“配置文件”
• 仓库里存在一层内部基础设施
• 很多构建、生成、任务编排能力已经被封装成内部复用模块

这对组件库作者来说是一个很重要的启发：

当组件库规模变大后，“构建系统”本身也应该被当成项目的一部分来设计，而不是一堆零散脚本。

docs 和 play 为什么要分开

这是很多人分析组件库时容易忽略的一点。

docs

更偏文档站和正式展示：

• 安装说明
• API 说明
• 组件示例
• 对外沟通

play

更偏内部调试和快速验证：

• 开发中试验组件
• 验证某个交互和样式
• 快速复现问题

把这两者分开，是一种很成熟的工程习惯。
因为“给用户看的文档演示”和“给开发者调试用的 playground”关注点并不相同。

ssr-testing 和 typings 为什么说明项目很成熟

很多小型组件库只关注“浏览器里能跑”，但成熟库必须继续考虑：

• SSR 场景是否兼容
• 类型声明是否完整

所以：

• ssr-testing 体现的是运行环境边界意识
• typings 体现的是类型交付意识

这两者都不是“锦上添花”，而是大型公共组件库必须面对的交付问题。

这个案例最值得你借鉴什么

如果你不是要照搬 element-plus 的技术栈，那么更值得借鉴的是它的工程思路：

1. 不把组件库等同于“若干组件源码”
2. 把文档、playground、类型、测试、构建一起纳入项目结构
3. 当规模变大后，把内部构建能力也模块化

这三点，比单纯模仿它某个 rollup 配置更有价值。

分析这种大型组件库时，建议带着这些问题看

1. 它怎样组织“对外入口”和“内部实现”边界？
2. 它怎样把组件、样式、类型、文档串起来？
3. 哪些能力是为使用者准备的，哪些能力是为仓库自身维护准备的？
4. 它在哪些地方明显体现出“规模化组件库”的工程意识？

一句话总结

element-plus 这个案例真正值得看的，不只是它怎么做按钮和表单，而是它怎样把一个 Vue 3 组件库做成一套完整、可长期维护的工程系统。