前言

隨著項(xiàng)目的界面越來(lái)越多，webpack的熱更新越來(lái)越慢，有時(shí)會(huì)達(dá)到5,7s之久，這對(duì)于開(kāi)發(fā)效率影響是非常巨大的。

分析過(guò)程

于是今天就針對(duì)這個(gè)分析了一下熱更新慢的原因，步驟如下

首先先在package中的啟動(dòng)命令加上

--progress --watch --colors --profile

先解釋一下這幾個(gè)參數(shù)的含義

• --progress 構(gòu)建進(jìn)度
• --watch 實(shí)時(shí)監(jiān)測(cè)
• --profile 編譯過(guò)程中的步驟耗時(shí)時(shí)間

加上了這幾個(gè)參數(shù)，重啟項(xiàng)目，就可以開(kāi)始觀察耗時(shí)時(shí)間了，修改了某個(gè)文件之后，查看控制臺(tái)，如下

圖中紅色部分就是耗時(shí)最長(zhǎng)的地方了，好了，發(fā)現(xiàn)了耗時(shí)時(shí)間長(zhǎng)的地方了，經(jīng)過(guò)百度搜索，發(fā)現(xiàn)也有個(gè)問(wèn)題和我這個(gè)非常類似，他的原因是因?yàn)槭褂昧藆glifyJsPlugin插件，這么一想，我的項(xiàng)目中的webpack配置中也用到了這個(gè)插件，于是把這個(gè)插件移到生產(chǎn)環(huán)境中使用，修改之后重啟項(xiàng)目，修改某個(gè)文件之后，查看控制臺(tái)，如下

效果非常驚人，總的耗時(shí)已經(jīng)在1,2s之內(nèi)了，效率提高了不少！！如果也有這種煩惱的小伙伴也可以試一下哦

另一種解決方案

這種方案的思路為，開(kāi)發(fā)環(huán)境中，每人負(fù)責(zé)的都是一部分模塊或者組件，所以熱更新可以只編譯自己當(dāng)前需要的頁(yè)面，而沒(méi)必要把所有的頁(yè)面全部編譯。創(chuàng)建一個(gè) selfConfig.js 設(shè)置需要保存的頁(yè)面，然后在 webpack 配置中，配置，只屬于需要的頁(yè)面去編譯熱更新。加快開(kāi)發(fā)環(huán)境中的編譯速度。

// selfConfig.js
module.exports = [
'imScence',
'mLogin'
];

// webpack.base.conf.js 
// 部分關(guān)鍵代碼
const selfConfig = require("./selfConfig");

for (let moduleName of modules) {
if (selfConfig.length === 0) {
devEntries[moduleName] = path.join(resolve('src'), 'modules', moduleName, 'main.js');
} else {
if (selfConfig.includes(moduleName)) {
devEntries[moduleName] = path.join(resolve('src'), 'modules', moduleName, 'main.js');
}
}
buildEntries[moduleName] = path.join(resolve('src'), 'modules', moduleName, 'main.js');
}

以上事例設(shè)置完成后，只會(huì)熱更新兩個(gè)頁(yè)面，但是這種方案的弊端是，其他頁(yè)面本地環(huán)境將是白屏打不開(kāi)（因?yàn)閴焊鶝](méi)編譯），所以這種方案還是根據(jù)適合自己的場(chǎng)景使用。

注意： 每次修改 selfConfig.js 需要重起 webpack 服務(wù)。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論