天下苦webpack久矣,相信作为前端开发者一定经历过在项目迭代时间较长的时候经历漫长等待的这一过程,每一次保存都会浪费掉大量时间,这是webpack这种机制所带来的问题。
于是,尤大为我们带来了新一代前端构建工具:vite。
说起这个工具,相信各位也不会陌生了,因为vite已经出现很久时间了,现在已经出现了v4版本,查看其git仓库,发现其迭代变更速度很快,也侧面说明了这一工具在前端圈的火热,其突出的特点就是快,快在什么地方呢,就是我们的开发阶段,使用vite构建的项目在开发阶段可以为我们节约大量时间,但是对于我们没有接触过这一技术栈的同学,存在一个比较尴尬的问题。
目前vite主要默认是支持给vue3使用的,并且如果使用官方的cli创建的项目一样会默认使用vue3去构建项目,此时对于一些vue2的老项目就显得不友好了,那么我们如何针对于vue2
的项目进行构建工具的升级呢,在将webpack升级到vite的过程中,你会遇到哪些坑呢,让我来带你跨过去吧,在此之前,我们去简单了解下什么是vite,有什么优势。
什么是Vite
Vite下一代的前端工具链
官方只有这么一句话,我们就可以明确其是一个前端工具链,其出现的时间已经很久了,到现在的v4版本已经经历了很多变动,在我升级公司的项目的时候还是v3,没想到只是过了一个周末打开官网已经到v4了,这迭代速度是蒸滴快啊。
这么长的时间,其实众多同学都知道其是一个打包构建工具,我们就不过多废话,直接进入进入主题,我们先了解这几个点:
Vite为什么之前不出来?
在浏览器支持 ES 模块之前,JavaScript 并没有提供的原生机制让开发者以模块化的方式进行开发。这也正是我们对 “打包” 这个概念熟悉的原因:使用工具抓取、处理并将我们的源码模块串联成可以在浏览器中运行的文件,这就是webpack这类工具的工作原理,他们需要通过解析目录树拿到所有资源文件然后转化为浏览器可以识别的文件才能最终输出供浏览器使用,这个过程所需要的时候,不论是在初期编译阶段还是修改文件的热更新阶段都不可避免,当开发的项目越来越大的时候,所需要的编译时间也就越来越长了,我们也就遇到了性能瓶颈,往往单单启动项目就需要花费很多的时间,甚至是数分钟。
Vite 旨在利用生态系统中的新进展解决上述问题:浏览器开始原生支持 ES 模块,且越来越多 JavaScript 工具使用编译型语言编写。
也正是因为浏览器原生支持了es模块,才让vite这类工具得以出现。
什么是Es模块
所以我们也顺带了解下什么是es模块,浏览器原生支持了对前端有什么影响,有何用处呢?
其实我们所说的es模块就是我们常说的ESM,ESM是一种规范,在早期,我们的浏览器只支持script标签引入,这样的使用方式在很多场景下就会显得很麻烦,在NodeJs出来之时携带了CommonJS规范也就是我们所说的CJS规范,但是其只适用于服务端,所以为了迎合客户端的需求,主要是针对浏览器,便有了针对于客户端的规范Asynchronous Module Definition,简称AMD规范的出现,但是这些规范出现的仓促并且也只是为了解决当时的一小部分问题,这些社区提出的规范终究只是为了解决一时的需求,随着历史的发展,新的模块化规范不断涌入、消亡。
直到ESM规范被提出。ESM规范是ES标准的模块化规范,他的早期讨论可以追溯到2019年。到此为了,ESM的出现自身有诸多的优点,这里就不概述了,有兴趣的朋友可以自己去查阅,我们在此只需要了解这些规范出现的原因和历史背景即可,ESM虽然好,但是由于CJS规范已经存在较长时间了,所以市面上已经有了非常多的CJS规范的包,让这些所有包从CJS切换到ESM显然不太现实,于是便出现了这样的场景,ESM与CJS共存,并且这将是一个长期趋势。
如何解决这一痛点?
1.两种规范的不同我们很好理解,简单来讲,我们目前开发的项目有的属于nodejs项目,有的属于前端项目,两边的包的规范明显不同,但是有的工具的包很明显我们都可以用,那么我们一般如何去做呢?比如在babel中使用babel-plugin-transform-commonjs可以将CJS规范的代码转换为ESM规范,在vite或者webpack中都有不同的工具可以转换,一般这一任务都会交给这些工具。所以日常开发中,开发者对这些规范的感知并不明显。 2.第二种,为了一刀切解决当前ESM、CJS、浏览器script标签导入这3种规范互相不兼容的情况,提出了兼容三者格式的UMD(Universal Module Definition)规范,在使用打包工具打包类库的时候往往会有一个打包类型的选项,很多包都会选择UMD就是这个原因。
但是很显然这些方式是一定存在痛点的,虽然看起来将不同规范在工具集上进行了抹平差异,但是由于一些兼容性的问题,这些差异就会被放大,所以当多个工具出现在一个项目的时候,实际是就是为了抹平这些差异化的存在。
上面的这些规范是一些题外话了,和本文关系不大,但是值得每一位前端开发去了解,正是因为ESM规范的优秀,才使得浏览器会去原生支持他,当然对于这些规范一般都是先定义后实现,这个定义在前期已经被定义了,只是浏览器的支持是慢慢跟上的,总而言之,在现在,我们已经可以去使用这一特性了。
浏览器原生支持ESM有什么用?
这里的东西也相对较多,我们就长话短说,在之前,我们都是通过script标签进行引入的。
这个标签引入的脚本负责交互。
但是一个大型的项目当然不仅仅只有一个js文件,对于繁多的文件,我们想要很好的管理就显得有些难度,于是我们借助webpack这类工具,其将我们的文件打包为bundle.js,再将文件。这意味着我们的前端开发工作流从“石器时代”跨越到了“工业时代”,但是对浏览器来说并没有质的改变,它所加载的代码依然一个 bundle.js ,整体引入到我们的项目当中。
但是随着浏览器对 ES Module 标准的原生支持,改变了这种情况。目前大多数浏览器已经支持通过