背景
近期全网都在推vite，仿佛人人都在学
带着好奇心和新知识的敬畏，展开了基于vite构建的phaser项目。
关于vite做了啥，指路：vite 原理浅析
我们需要准备什么？
node>=12.x.x满足上面一点就够了，最好的话npm是taobao源，毕竟运行npm i时，初始依赖有92mb。
为什么采用？优势？
浅析原理，phaser的构建，vite compare webpack
phaser的构建不同于react、vue等技术框架，它可以不基于前者，完全独立渲染维护自己的canvas画布即可。在业务场景中实际编写的是以：
- game实例
- scene
- container
- gameObjects
- .... 等等些列单一游戏矢量类
集合范围从上至下递减，官方的做法是：
1.推荐采用ts维护phaser项目；
2.基于条件1，通过game创建游戏实例后，其任何子元素通过class方式编写。
例如可以实现Scene、container、gameObjects等矢量的继承，也可以实现矢量的抽象。
所以可以理解phaser是一个all in typescript的项目
既然是all in ts，那么我们实际编写的都是ts文件，在随着项目不断增大，类与类之间依赖关系逐渐复杂的情况下，在dev环境每次( command || ctrl ) + s保存，都会全量打包一个bundle.js交给浏览器解析，即便是修改了一句console.log ，这无非是浪费内存和时间的一件事。
例如：存在三种文件文件关系：
// a.ts
export default class A {};
// b.ts
export default abstract class B {};
// c.ts
import A from 'a.ts';
import B from 'b.ts';
export default class C extends A implements B {}
最理想的条件下（不考虑翻译、转码），如果以C文件为入口，打包完成的文件，按照webpack的方式会形成：
// bundle.js
class A {};
abstract class B {};
class C extends A implements B {}
那如果是vite，它会怎么处理这种依赖关系呢？
还是以C文件为入口，如果读到import，会重写引入模块路径，然后发起HTTP请求，koa中间件处理静态资源并返回。
在上述过程中，完全没有因为一句更改而引发的全量bundle。
vite提供了一种高度依赖ESM关系的监听-解析-重加载机制，虽然达不到针对*.vue、*.tsx文件内部更为详细的拆解，但这种思路是非常可取的，理论上对dev环境编译项目能有速度上的提升。
如何构建一个 all in ts & on vite 的 phaser项目呢？
在通过npm init @vitejs/app 'projectName'创建时，模板任选熟悉的其一即可，例如笔者，我更偏好于Typescript开发，那就vue+ts。
// node >= 12.0.x
// 创建初始化项目模板
npm init @vitejs/app `your project name`
// 选择模板
// 启动项目
npm i && npm run dev
// 享受闪电般的开发速度
使用感知？直观对比
快吗？ 是真的快！
尝试分别通过vite、webpack构建了两个phaser项目基座，仅仅初始化一个base场景。
在没有引入HSWP（ HardSourceWebpackPlugin ）读写缓存的情况下，编译-加载速度分别为：
vite：563mswp：1490ms
附上base项目依赖文件关系：
遇到的问题
以上实现phaser项目是基于vite@1.0.0-rc.13开发，尝试升级过正式版vite@2.0.x,但是遇到了引用CJS全局模块变量的错误，希望大神们可以为我解答一下。
总结
上文就是笔者学习vite并运用的全过程，其中有很多值得学习的点都一带而过，例如：
esbuild构建为什么快？（ go编写 编译成本地二进制，翻译，内存消耗低，保证“编译速度”第一原则；koa中间件如何处理src文件或者node_modulesvite和react的快乐组合 （ 后续更新- .etc 等等
上述技术在掘金有着很多优秀的作者进行了解读、分析，就不再班门弄斧，下面附上链接供大家一起学习。
