最近在准备把团队内部的一个 PC 端 UI 库按照 npm 的组织方式抽离成单独的项目，一直在纠结如何打包。

    先简单的说一下需求：

    1. 源代码需要使用 typescript，样式使用 sass
    2. 最终打包后的代码能发布到 npm，并且不丢失 TS 类型定义
    3. 支持按需引用（在只使用一个模块时，可以不引入其他无关模块）
    4. 包的最终大小，尽可能小

    用什么工具打包，我收集到现在 js 打包工具组合如下。

    1. webpack + babel
    2. rollup + babel
    3. rollup + typescript
    4. tsc + sass

    在选择工具时，我一开始就抱有追求完美的想法。

    尽可能使用少的技术栈，因为只需要打包 TS 与 Sass，又要保证最后打包的大小比较小，第一时间排除了以 Webpack 为核心的第一种方向。

    一开始就尝试 rollup + typescript，折腾了很久，出现了各种小问题，最后发现现很难使用一种打包方式满足所有的场景。但我一直想用一种打包方式满足所有场景，这种思路折磨了我很久。

    最后发现，换一种思路，就豁然开朗了，那就是用不同的打包方式来满足不同场景。我下面就来分析三种思路，以及其优劣势如下。

    打包方式 优势 劣势

    1. 打包成一个文件
    		 使用方便，包小 不可按需引用，实现成本适中

    2. 每个文件单独编译
    		 可按需引用 引用复杂，重复代码多，实现成本低

    3. 入口汇总，文件按模块打包
    		 使用方便，可按需引用 按需引用需要工具，总代码比较多
    实现成本较高

    满足的场景如下：

    第一种方式：适合库的重度使用者，大部分组件都使用时，无需按需引用来减少，使用项目的大小。

    第二种方式，适合偶尔使用我们的组件的人群，不需要任何配置，用完就走，无压力。

    第三种方式：适合高级用户，需要在自己的项目做自定义配置，在自己的项目做最终的打包汇总与优化。

    既然三种方式都有人使用，为什么步骤实现三种方式，供不同的人群选择使用。为了尽早的提供价值，因为当软件发布时，他的价值才能体现。

    1. 首先，先实现第二种打包方式，让大部分人可以使用先。
    2. 其次，实现第三种，让追求完美的用户也可以使用。
    3. 最后，实现第一种，满足直接通过 html 引入 js 的用户。

    完美的错觉就是，我们往往会等待自认为完美后再提供价值，一个时间成本太高，而且最初的方案往往不是最完美的解决方案。可以追求完美，但需要时间，也需要分解与试错。