当webpack有了vite的速度你会喜欢吗？

前言

本文主旨意义是在于和你们分享本身的脚手架，以及在开发过程当中受到的一些心得。

首先阅读此文能够看成为仅仅了解一个新的工具，同时因为进行了webpack和vite双向的说明，中间会参杂了必定的vite和webpack的内容解析。（主要进行思路分析不涉及具体源码，感兴趣的能够本身去阅读源码）

对于分析不感兴趣的大佬能够直接进入v5-run小结

#老规矩打一波推广
vue组件平台服务器最近搞了新的服务器了，欢迎你们去进行尝试！
同时若是有大佬但愿能利用搭建公司的组件分析平台也能够找我。
项目采用docker部署，能够很方便搭建公司内部的一个平台。
线上访问地址：http://assemble.everbeon.top/assemble/#/Show/index
注：嫌背景粒子动画卡的能够点击右上角的小图标就能够关闭背景动画
复制代码

如何让webpack有vite的速度

webpack vs vite

首先这一个问题咱们要先将进行两段分析，webpack慢和vite快的缘由是什么？

webpack bundle everything

是的，这就是webpack慢的缘由，因为webpack对于全部运行资源进行了提早编译处理，对依赖模块进行了语法分析转义，最终的结果就是模块被打包到内存中。

vite Bundleless esbuild esmodule

在vite中就出现相反的状况了，遵循着打包少、预处理的方式，让vite只有在运行第一次的时候进行依赖的打包处理（package.json不变）。而且在运行中因为依赖着esmodule能够将文件采用import方式直接引入，这样就不用把文件打包到一块儿，并且采用esbuild对于语法的解析转换（如：ts、jsx等）这样就不用进行js解析ast语法树后再从新构建，这样第一能够节省大量的cpu以及内存空间、第二能够减小语法解析的大量时间，基本上能够达到时效性不用提早进行语法解析。

why webpack

在webpack的开发中，你们或多或少的都在利用着webpack的“方言”带来的便利。好比如下代码：

// require.context Api
require.context(directory, useSubdirectories, regExp)
...
// css导出变量给js
:export {
    theme: $--color-primary;
}
...
// 各类魔幻的路径
import App from 'App'
...
// 以及svg引入
<use :xlink:href="iconName" />
复制代码

能够说，webpack在给咱们带来方便的时候也同时把咱们给惯坏了！愈来愈脱离标准的es规范了，给咱们开了愈来愈多的后门可走，甚至咱们能够在咱们的页面中写一些node api同样给咱们搞定。（期待再多点这种方便的后门）在这种状况下咱们进行webpack迁移到vite就会出现一系列的报错，而且因为配置文件不熟悉rollup也同时给咱们的项目带来了不肯定性，那么我不想动我本来的项目就像体验一下vite飞通常的感受就是个人初始目标了。

how to do

把大象放进冰箱分几步？

• 把冰箱门打开
• 把大象放进去
• 关闭冰箱门

是的咱们的原理也若是放大象同样很是的简单，任何复杂的问题均可以简单化处理，且不要把问题想的过于复杂才是解决问题的最快途径

咱们主要内容也分为三步

构建url以及语法解析服务

这一步主要是为了让咱们的脚手架支持webpack特有的路径预处理判断，而且能够正常的解析咱们的vue文件。

三方依赖处理

这步做为依赖的收集处理，而且让其支持import方式导入，至关于webpack中的vender处理

webpack方言api实现

实现webpack的特殊api，如：:export {}、require.context

这样就实现了咱们整个目标路径。固然若是简单列一下架构的话，估计就须要这样的一张图来实现。

固然处理webpack方言实现以外（无法进行整合到这上面，那个算具体需求），会发现三方依赖并无在设计中，接下来咱们就重点讲一下这个三方依赖（涉及到vite的必定原理解析，能够了解到面试吹牛皮）。

why first node_modules

为何在vite中须要提早构建第三方依赖？官网给的解释有如下两点：

• CommonJS 和 UMD 兼容性
• 性能

可是！利用esbuild去构建达到兼容性和性能彷佛也不是问题，而且不进行预构建其实有一个隐性的好处就是能够减小运行时的node_modules依赖性，好比咱们能够手动实现一个相似yarn的包集中管理，这样咱们就能够完美的实现项目中无node_modules了，想一想都激动呢。那么问题点在哪呢？

esbuild中有一个选项为bundle: true

这个选项会将须要打包的入口文件的依赖进行所有打包，好比：我导入elementui，那么他就会将全部element须要的依赖通通打入到内部。（重要！请记住）

这个时候当咱们引入了elementui后，elementui内部使用的vue和项目中自己的vue是否是同一个呢？

答案：不是，由于elementui引入的是本身内部的vue，而项目中是经过单独引入的vue

webpack引入究竟是怎样引入？

在咱们的node_modules中你们能够去找一下这个现象，会发现element-ui中明明就须要不少依赖，可是他却没有或者只有不多的依赖，这些依赖每每都是在node_modules中的第一层。这样的结果是怎么样的呢？

在同一项目中，不一样工程依赖同一个npm，他们引入是相同的，而且是属于引用值至关于他们共享了这个npm的导出。好比a.js引入了 xxx.js将本来的导出的ceshi这个值修改为了2，那么当b.js引入的时候获取到ceshi这个值也是2而不是最开始的值了。

到这咱们就发现了最大的问题，在运行时去加载依赖没办法分析他们之间的引用关系，这样会致使最大的隐患问题!!!

因此vite进行了预处理的问题最大点是在于三方包之间的依赖关系问题。

vite为何能够预处理分析

这个答案其实很简单了，由于vite须要在入口的html中添加type="module"的script导入，而后将匹配script引入的导入做为esbuild的入口文件，这样esbuild就经过入口文件寻找各类依赖关系而后再加入插件分析依赖引入状态，就实现了感受高大上智能的预处理分析了。

v5-run

这就是让webpack有vite速度的神奇指令了，实现就是依照着上面所属完成的。

所以这里主要就讲解脚手架的使用以及配置。（暂时只能用于vue2开发）

地址合集

npm: www.npmjs.com/package/@se…

gitee: gitee.com/beon/v5-vue…

npm安装: npm i @seeyon-v5-vue/cli-run -g

运行指令： v5-run

配置文件

相似与各类配置文件，你须要在项目根路径下建立v5-run.config.js文件，并将其进行配置对象的导出。

module.exports = {
    // 服务运行的配置
    server: {
        // 和webpack proxy同样
        proxy: {
            [url: string]: {
		target: string,
		host?: string,
		headers?: {[key: string]: string}
		changOrigin?: boolean
            }
        }，
        // 是否开启http2模式（不稳定，尝鲜使用）
        http2：Boolean,
        // 重要，自动获取html路径为根路径和public路径，若是html不在须要手动添加如：['src/html/']
        enter: string[]
    }，
    // 各类设置的配置
    config：{
        // 配置svg引入到html中
        svgLoader： {
            // 引入svg文件夹路径
            path: string,
            // svg引入名称配置如：my-svg-[name],引入名称则为（svg文件名为app.svg）:my-svg-app
            symbolId: string
        },
        // 全局导入less、scss等
        styleLoader: {
            // 前面为引入类型如less、scss，数组为引入文件如['src/assets/index.scss']
            [loadStyle: string]: string[]
        },
        // 全局变量配置如：_(loadsh)
        global: {
            // 前面为全局名称如： _,后面为引入方式好比loadsh,数组则为某一项好比[loadsh, map],那么就会得到loadsh.map的对象引入
            [name: string]: string | string[]
        }
    }
}
复制代码

使用教程

第一步配置v5-run.config.文件

基础配置文件,能够按照需求改就能够了

module.exports = {
    server: {
        enter: ['./src'],
        http2: true,
	proxy: {
            "/dev-api": {
		target: 'http://localhost',
		changOrigin: true
            }
        }
    },
    config: {
        svgLoader: {
            path: 'src/icons',
            symbolId: 'icon-[name]'
        },
        global: {
            _: "lodash",
            $: "jquery",
            jQuery: "jquery"
        },
        styleLoader: {
            less: [path.resolve(__dirname, "./src/assets/styles/variable.less")]
        }
    }
};
复制代码

第二步执行v5-run指令

看到服务开启成功后为成功开启

第三步访问网页（注意）

在网页访问路径须要手动输入到你的入口文件，好比：http://localhost:3000/src/html/index.html 其次，最好加入index.html路径，不然有可能会出现某些路径解析少一层的问题。访问错误的时候会出现提示，而且有问题也会出现提示页面，能够双击错误请求页点进去查看错误缘由

问题点

那这一块做为单独说明主要是强调现阶段该实现而没有实现的重要功能点。

没有热更新

暂时没有作热更新，虽然有现有实例，可是仅仅做为本人使用而言，热更新暂时意义不大（项目较为特殊）。

webpack兼容性

做为兼容性只是作了几个经常使用的设置以及配置，可以知足大多数标准的项目而已，特殊项目须要特殊处理，暂时没法解决，若是有问题能够直接联系我，能够查看脚手架问题缺点（说不定下个版本就修复了呢）。

三方依赖每次开启都会处理

其实这个是个比较好处理的问题，可是本人在使用的时候发现处理时间较短，因此暂时未做处理（就是懒）。

css文件中的路径处理

好比element中scss就有这样$--font-path: "~element-ui/lib/theme-chalk/fonts"一句，须要在其上面进行注释//v5-run-style-path,就会处理这个路径参数。（只有参数须要添加，@import、正常url都不须要 ）

结尾

你们感兴趣去看gitee的话也能够看到，本项目只是整个脚手架项目的一块，剩下的内容都还没加上去，后期会将处理方式、代理方式、管理三方包方式所有抽出来，作成一个完整的脚手架项目。如今只是进行项目可行性的制做。总体项目使用了ts进行开发，可是因为没有具体拆分因此尚未上单元测试。

做为一个新的脚手架内容，我认为提升开发效率以及项目稳定性是最重要的，这也是为何没有一昧的进行强行替换vite做为生产，当出现问题的时候能够直接使用webpack进行处理。（好比：ie状况、兼容性测试等问题）因此项目不失为咱们在切换到使用esmodule上的一个尝试阶段，让咱们去变相性的让webpack拥有着和vite同样的速度。

本项目中的三方依赖处理，有必定程度借鉴vite，因此现阶段代码较为类似，这也是为何我没有急着作初始化缓存信息的缘由，由于未来目标不同，因此后期会进行修改该块内容。

这就是本文所有内容了，欢迎各位大佬进行讨论，本人微信为:Dawn_web，qq为：962717593，有任何问题均可以联系本人。

我是BEON，一个千方百计帮助团队提升效率的前端工程师