Vite lib 模式下外部依赖清单怎么定

用 Vite 打包组件库时，很多问题表面上像是 Rollup 配置细节，实际上根因常常在于 external 依赖没想清楚。哪些依赖应该跟着组件库一起打进去，哪些应该交给宿主项目安装，这个决策越晚做，后面返工越大。

我自己的习惯是先按依赖角色来分。像 react、vue 这类运行时宿主依赖，通常就应该 external；而一些只在构建时使用、或确实希望封装在组件库内部的工具依赖，才考虑打进产物。只要这一层没分清，后面就容易出现重复依赖、样式冲突或者 bundle 体积异常。

还有一个很实际的问题是版本策略。external 不只是技术配置，它还意味着你在把兼容范围交给使用方。所以 peerDependencies、文档说明和示例工程最好一起配齐，否则别人装上库以后很难知道问题出在哪。

我越来越觉得，组件库构建不是“把代码打出来”这么简单，而是要把运行边界说明白。external 清单其实就是这条边界的一部分。

边界先定好，构建配置才不会一直补丁式地往上叠。

前端里的很多“体验问题”本质上都是边界问题

围绕「Vite lib 模式下外部依赖清单怎么定」这类前端话题，最常见的误区是先去追求框架技巧，再去补组件边界和状态来源。可一旦项目规模上来，真正让代码变脆的，往往不是少用了某个 API，而是数据获取、缓存失效、交互 pending、组件拆分和构建产物之间没有形成清楚约定。框架升级只会把这些隐性问题更快地暴露出来。

我会先做的落地检查

• 先明确状态由谁拥有、什么时候重置、什么时候延迟更新，避免组件自己偷偷维护第二份真相。
• 把路由、缓存、构建配置和产物入口拆成可独立验证的边界，不要把所有约定都留在默认行为里。
• 一旦某个点已经影响到交互一致性、渲染成本或团队协作效率，就应该把它写成约束，而不是继续靠经验口口相传。