背景

带着好奇心和新知识的敬畏，展开了基于vite构建的phaser项目。

关于vite做了啥，指路：vite 原理浅析

我们需要准备什么？

• node >= 12.x.x

满足上面一点就够了，最好的话npm是taobao源，毕竟运行npm i 时，初始依赖有92mb。

为什么采用？优势？

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：563ms
• wp：1490ms

附上base项目依赖文件关系：

遇到的问题

以上实现phaser项目是基于vite@1.0.0-rc.13开发，尝试升级过正式版vite@2.0.x,但是遇到了引用CJS全局模块变量的错误，希望大神们可以为我解答一下。

总结

上文就是笔者学习vite并运用的全过程，其中有很多值得学习的点都一带而过，例如：

• esbuild构建为什么快？（ go编写 编译成本地二进制，翻译，内存消耗低，保证“编译速度”第一原则；
• koa中间件如何处理src文件或者node_modules
• vite和react的快乐组合 （ 后续更新
• .etc 等等

上述技术在掘金有着很多优秀的作者进行了解读、分析，就不再班门弄斧，下面附上链接供大家一起学习。

esbuild：下一个时代的打包工具esbuild

逐行分析Koa中间件机制