{T}

TS 库工具选型：编译器、运行时与打包工具

概述

课程前半段用 Vite 完成 Vue 组件库的基础打包，后半段又单独讲纯 TS 库构建，并不是在否定 Vite，而是因为两类项目目标不同：Vue 组件库要处理 .vue、样式、调试页面和 Web Server；纯 TS 库可能是 Node 侧工具库、插件、脚本、SDK，重点是把 TypeScript 产出成合适的模块格式。正因为目标不同，工具选择也不该套同一个模板。这一节真正要解决的是建立工程化分层：编译器、运行时、打包工具不是同一种东西，选错层就会导致「把 tsx 当打包工具」「把 Vite 和 Rollup 当完全同层」这类误区。

学习目标

  • 区分 Vue 组件库与纯 TS 库的构建目标差异，理解为何要分开讨论
  • 建立编译器 / 运行时 / 打包工具三层分类，避免工具角色混淆
  • 理清 tsc、Babel、esbuild、SWC 在编译器层各自的侧重点
  • 理解 tsx、jiti 只是运行时增强，不替代正式构建流程
  • 掌握纯 TS 库「零配置优先」的选型思路，并留意 tsup / unbuild / tsdown 的生态变化

一、为什么 Vue 组件库先用了 Vite，纯 TS 库又值得单独讨论

课程里选 Vite 打包组件库，理由很朴素：不想从零配置一堆 Rollup 插件，同时希望顺手就有 Web Server 调试。Vite 官方也明确库模式用的是面向库发布的 Rollup preset，所以它在「开发调试 + 库构建」之间提供了更顺手的默认体验。

但纯 TS 库和组件库的目标不一样：

  • Vue 组件库：关注组件、样式、Demo、调试页面；
  • 纯 TS 库：关注产物格式、入口、发布。

所以课程不是在否定 Vite，而是在说：浏览器 / 框架导向的库，Vite 很方便；纯 TS 库、Node 工具库，可以考虑更轻量、更直接的构建工具。项目类型决定工具，而不是「工具是否流行」。

二、编译器、运行时、打包工具是三层不同东西

工具一多最容易混乱。真正要记住的是三个层次：

  1. 编译器：负责语法转换，把 TS / 新语法 JS 转成目标环境可识别的代码；
  2. 运行时 / Loader：负责让你在开发期「直接跑」TS 或 ESM，更像执行环境增强器；
  3. 打包工具：负责把多个模块组织、合并、输出成最终产物。

如果这三层不分开，就会出现常见误区：把 tsx 当成打包工具、把 esbuild 只当编译器、把 Vite 和 Rollup 当成完全同层。Vite 本身更像「开发服务器 + 构建工具整合层」，不是单纯的传统 bundler。选型时先问自己缺的是「转换」「执行」还是「打包」。

三、编译器层：tsc、Babel、esbuild、SWC 侧重点不同

这几类常见编译器用更清晰的话概括：

  • tsc：TypeScript 官方编译器，负责类型检查、声明生成、TS 语法编译；
  • Babel：官方定义就是 JavaScript compiler，擅长语法转换和插件生态扩展；
  • esbuild：定位是 extremely fast bundler，同时具备快速编译与打包能力；
  • SWC：Rust-based platform for the Web，既可编译也提供 bundling 能力。

课程最想强调的是速度差异，方向没错，但整理成知识时不能把「谁一定最快」写成绝对真理。更稳的结论是：esbuild 和 SWC 都明显偏向高性能路线，tsc 和 Babel 更偏向类型能力、语法能力和生态深度。

bash
tsc --project tsconfig.json
npx babel src --out-dir dist
esbuild src/index.ts --bundle --format=esm --outfile=dist/index.js
npx swc src -d dist

tsc 最大价值不只是编译，还包括类型系统和声明文件能力；Babel 的优势在于成熟插件生态而非纯粹拼速度；esbuild 和 SWC 谁更快要看你自己的项目测试结果。

四、运行时层：tsx、jiti 只解决「直接跑 TS」

tsx 官方把自己定义为 TypeScript Execute，一个增强版 Node.js 运行方式；jiti 强调 Runtime TypeScript and ESM support for Node.js。这类工具的价值是让你开发时不必先手工编译再执行，更方便跑脚本、配置文件或开发期工具。

bash
npx tsx ./script.ts
npx jiti ./script.ts

但它们不等于正式发布产物、npm 包交付结果或完整构建链。运行时工具提升的是开发体验，不是发布质量；tsx 官方也明确它不负责类型检查，类型检查应另行处理。这类工具和 bundler 是配合关系，不是替代关系。

五、纯 TS 库选型：零配置优先与生态变化

课程不主张一上来就裸写 Rollup，原因很直接：裸配 Rollup 学习成本更高、要自己摸插件生态、要自己配 CJS / ESM / CSS / 类型 / 入口 / 外部依赖。更适合大多数人的起步是先用零配置或少配置工具，典型代表是 tsup 和 unbuild——它们的核心价值不是底层能力更强，而是帮你封装掉大量默认配置，更快产出可发布结果。

bash
npx tsup src/index.ts --format esm,cjs --dts
npx unbuild

但要注意课程语境和当前生态的差异：tsup 仍是经典工具，但官方 README 已写明 not actively maintained，建议考虑 tsdown；unbuild 仍是 UnJS 生态重要构建器，同时在实验 obuild 作为 successor。所以今天整理这节课，最稳的结论是：课程推荐 tsup / unbuild 在当时成立，新开项目除了 unbuild 还应顺手关注 tsdown。「零配置」不代表能力弱，而是先内置常见最佳实践；上层工具满足不了时再回到底层 Rollup 是更自然的演进顺序。

六、benchmark 不要当成绝对结论

课程里列了不少 esbuild 与 SWC 的 benchmark，这对培养性能意识有帮助，但如果直接整理成绝对结论，后面很容易误导。当前更稳的方式是：SWC 官方强调对 Babel 有显著性能优势，esbuild 定位就是 extremely fast bundler，但谁更快依赖项目规模、同步 / 异步场景、是否含类型生成、是否含打包、插件链与 IO 开销。

所以这节课最该沉淀的是方法论而非某次 benchmark 数字：先看技术栈兼容性，再看工具生态支持，最后看项目里的真实测速结果。benchmark 是参考不是法律，工具选型也不该只看单次编译时间，生态稳定性、配置复杂度、类型产物质量同样重要。

七、按需下沉：从上层工具到 Rollup 的演进路径

课程在 Vue 组件库阶段选择 Vite 而非直接裸配 Rollup，给出的理由很朴素也很现实：不想从零开始配一堆 Rollup 插件，同时希望顺手就有 Web Server 可以调试。这两个理由都成立，而且 Vite 官方也明确库模式用的是面向库发布的 Rollup preset——所以在「开发调试 + 库构建」之间它提供了更顺手的默认体验。

但这不意味着 Rollup 被淘汰。课程口径属于当时生态语境，当前 Vite 主线也在持续吸收 Rolldown 等新能力。更准确的演进路径是「先用 Vite / tsup / unbuild 这类上层工具快速起步，遇到复杂构建需求再下沉到 Rollup 做细配」：

  • 上层工具：封装了常见最佳实践，适合起步和大多数纯 TS 库；
  • 裸配 Rollup：更底层、更自由、更细粒度，适合需要插件级控制和复杂输出流程的场景。

Webpack 并不是不能做这些事，只是对当前课程场景来说不够轻。选型的关键不是「记住哪个工具最流行」，而是先判断项目缺的是转换、执行还是打包，再据此决定停在哪一层。上层工具满足不了时再下沉，比一开始就过度设计更稳。

理解了分层和演进路径后，下一节就直接用 tsup 把这套思路落成最小可跑的 TS 库工程，而不再停留在选型讨论。

常见问题

问题原因解决方案
想做纯 TS 工具库却直接搬 Vue 组件库那套 Vite 模板项目类型和工具层次没分清先判断自己做组件库、工具库还是 Node 插件
把 tsx / jiti 当成打包工具混淆了运行时和 bundler记住它们主要解决「开发时直接运行 TS」
看到 benchmark 就断言 esbuild 或 SWC 一定更快把单次测试当通用真理在自己项目里做真实测速再决定
一上来裸写 Rollup 配置成本太高过早下沉到底层工具先尝试 tsup / unbuild 这类上层简化工具
以为课程推荐 tsup 就代表新项目也首选它忽略工具生态在演进补看当前状态：tsup 可用但维护下降，tsdown 值得关注
不知道何时从 tsup / unbuild 切到 Rollup缺少选型边界判断当需要细粒度插件控制或默认配置覆盖不足时再下沉

延伸阅读