當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，一個千方百計幫助團隊提升效率的前端工程師