我们在设计框架的过程中应该考虑的。
- 我们的框架应该给用户提供哪些构建产物？
- 产物的模块格式如何？
- 当用户没有以预期的方式使用框架时，是否应该打印合适的警告信息从而提供更好的开发体验，让用户快速定位问题？
- 开发版本的构建和生产版本的构建有何区别？
- 热更新（hot module replacement，HMR）需要框架层面的支持，我们是否也应该考虑？
- 当你的框架提供了多个功能，而用户只需要其中几个功能时，用户能否选择关闭其他功能从而减少最终资源的打包体积？
2.1 提升用户的开发体验
警告信息 + 直观的输出内容
例如：
- 当我们创建一个 Vue.js 应用并试图将其挂载到一个不存在的 DOM 节点时，就会收到一条警告信息。
- 在开发环境下初始化自定义 formatter 的
2.2 控制框架代码的体积
DEV 常量为true在开发环境中是肯定存在的
在开发环境中为用户提供友好的警告信息的同时，不会增加生产环境代码的体积
2.3 框架要做到良好的 Tree-Shaking
Tree-Shaking 指的就是消除那些永远不会被执行的代码，也就是排除 dead code
想要实现 Tree-Shaking，必须满足一个条件，即模块必须是ESM（ES Module），因为 Tree-Shaking 依赖 ESM 的静态结构。
Tree-Shaking 中的第二个关键点——副作用。如果一个函数调用会产生副作用，那么就不能将其移除。
注释代码 /#PURE/，其作用就是告诉 rollup.js，对于 foo 函数的调用不会产生副作用，你可以放心地对其进行 TreeShaking
顶级调用+函数内调用
foo() // 顶级调用 function bar() { foo() // 函数内调用 }
对于顶级调用来说，是可能产生副作用的；但对于函 数内调用来说，只要函数 bar 没有被调用，那么 foo 函数的调用自然 不会产生副作用。因此，在 Vue.js 3 的源码中，基本都是在一些顶级调 用的函数上使用 /#PURE/ 注释。当然，该注释不仅仅作用于 函数，它可以应用于任何语句上。该注释也不是只有 rollup.js 才能识别，webpack 以及压缩工具（如 terser）都能识别它。
2.4 框架应该输出怎样的构建产物
Vue.js 的构建产物除了有环境上的区分之外，还会根据使用场景的不同而输出其他形式的产物。
使用
在 rollup.js 中，我们可以通过配置 format: 'iife'来输出这种形式的资源
直接引入 ESM 格式的资源
不过随着技术的发展和浏览器的支持，现在主流浏览器对原生 ESM 的支持都不错，所以用户除了能够使用
<script type="module" src="/path/to/vue.esm-browser.js"> </script>
rollup.js 的输出格式需要配置为： format: 'esm'。
使用 (process.env.NODE_ENV !== 'production') 替换 DEV 常量
（详情见书）
无论是 rollup.js 还是 webpack，在寻找资源时， 如果 package.json 中存在 module 字段，那么会优先使用 module 字段指向的资源来代替 main 字段指向的资源。
{ "main": "index.js", "module": "dist/vue.runtime.esm-bundler.js", }
Node.js 中通过 require 语句引用资源
当进行服务端渲染时，Vue.js 的代码是在 Node.js 环境中运行的，而非浏览器环境。
资源的模块格式应该是 CommonJS，简称 cjs。
为了能够输出 cjs 模块的资源，我们可以通过修改 rollup.config.js 的配置 format: 'cjs' 来实现。
2.5 特性开关
对于用户关闭的特性，我们可以利用 Tree-Shaking 机制让其不包含在最终的资源中。
该机制为框架设计带来了灵活性，可以通过特性开关任意为框架 添加新的特性，而不用担心资源体积变大。同时，当框架升级 时，我们也可以通过特性开关来支持遗留 API，这样新用户可以选择不使用遗留 API，从而使最终打包的资源体积最小化。
用户可以通过设置 VUE_OPTIONS_API 预定义常量的值来控制是否要包含这段代
码。通常用户可以使用 webpack.DefinePlugin 插件来实现：
2.6 错误处理
第一个办法是让用户自行处理，这需要用户自己执行 try...catch
第二个办法是我们代替用户统一处理错误,封装函数为用户提供统一的错误处理接口。
2.7 良好的 TypeScript 类型支持
使用 TS 的好处有很多，如代码即文档、编辑器自动提示、一定程度上能够避免低级 bug、代码的可维护性更强等。因此对 TS 类型的支持是否完善也成为评价一个框架的重要指标。
