发布TypeScript NPM包：tsc编译与Rollup打包的适用场景及疑问

1. 何时选择其中一种方式？ #

• 选tsc的场景：
  • 库是模块化结构，希望使用者能按需导入单个模块（比如import { funcA } from 'your-lib/dir/file1'），保留文件结构灵活性。
  • 库依赖少，或依赖都是标准NPM包，无需额外打包处理。
  • 追求极简构建流程，不想引入额外工具配置，降低维护成本。
• 选Rollup的场景：
  • 需要提供UMD/CJS/ESM等单文件包，方便用户直接通过<script>标签在浏览器引入，或Node环境中require整个库。
  • 需实现摇树优化（Tree Shaking），剔除未使用代码，减小包体积。
  • 要统一处理静态资源、转译特殊语法（如高级JS特性转译为低版本兼容代码），或需要多格式输出（同时生成CJS和ESM）。

2. 打包的优势是什么？ #

虽然Rollup需要额外配置，但核心优势很明确：

• 体积优化：通过静态分析实现原生摇树优化，自动移除未被引用的代码，大幅缩减包体积，尤其适合包含大量工具函数但用户仅用到部分的场景。
• 多格式输出：可同时生成CJS（Node.js）、ESM（现代浏览器/ES模块）、UMD（兼容浏览器和Node）等格式，覆盖更多使用场景。
• 代码合并与依赖隔离：将分散模块合并为单文件，避免用户处理多文件依赖；可通过external配置排除第三方依赖，让依赖由用户项目自行管理。
• 一站式构建能力：配合插件可完成TypeScript转译、代码压缩、polyfill处理、静态资源打包等全流程操作。

至于可读性问题，可配置sourcemap方便调试；全局变量定义仅针对UMD格式的浏览器场景，ESM/CJS格式无需额外处理。

3. 如果tsc已足够，Rollup是否更适合Web应用及客户端而非库包？ #

并非如此。Rollup最初就是为库打包设计的，它的摇树优化和多格式输出特性对库来说非常实用：

• 若库需要同时支持Node.js和浏览器直接引入，Rollup的多格式输出比tsc更高效。
• 但如果是纯Node.js工具库且结构简单，tsc确实足够，无需额外引入Rollup。
• Web应用通常用Webpack（支持代码分割、热更新、更多资源处理），Rollup在应用场景下使用相对较少，但并非不能用。

4. 两种方式都支持摇树优化吗？这仅属于客户端打包器的配置吗？ #

• tsc：本身不支持摇树优化。tsc只是将TypeScript转译为JavaScript，保留模块结构，但不会分析代码引用情况并移除未使用部分。摇树优化需要依赖用户端的打包工具（如Webpack、Rollup）——只要库用tsc输出ESM格式，用户的打包工具就能对其进行摇树。
• Rollup：原生支持摇树优化，打包时就会剔除未被引用的代码，输出的包本身就是经过摇树后的结果。
• 摇树优化并非只属于客户端打包器：Node.js的现代打包工具（如esbuild、Rollup）也支持对Node库进行摇树，前提是库输出ESM格式。只是客户端场景对体积更敏感，所以摇树优化在客户端的应用更广泛。

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