「項(xiàng)目實(shí)戰(zhàn)」優(yōu)化項(xiàng)目構(gòu)建時(shí)間
背景
前幾天晚上下班的時(shí)候， 路過隔壁項(xiàng)目組， 聽他們?cè)诹捻?xiàng)目構(gòu)建的事：
現(xiàn)在線上打包時(shí)間太長(zhǎng)了， 修個(gè) bug 1 分鐘， 發(fā)布一下半小時(shí), 賊難受。
他們項(xiàng)目比較龐大， 線上構(gòu)建時(shí)間特別長(zhǎng)， 基本都在15分鐘以上。
和他們簡(jiǎn)單聊了會(huì)， 回去瞅了一下自己項(xiàng)目的構(gòu)建時(shí)間：
其實(shí)也挺長(zhǎng)的， 于是抽空優(yōu)化了一下， 效果還是比較明顯的。
優(yōu)化后：
在正文部分，我將分享的內(nèi)容主要是：
一些提升 webpack 打包性能的配置優(yōu)化大型項(xiàng)目構(gòu)建時(shí)間的一些思考
希望對(duì)大家有所啟發(fā)。
正文
我們項(xiàng)目不是很大, 是一個(gè)中型的國(guó)際化項(xiàng)目, 一百來個(gè)頁面。
之前本地構(gòu)建時(shí)間挺長(zhǎng)的，初次啟動(dòng)要三次分鐘， 后面我配置了 Vite, 本地啟動(dòng)時(shí)間降低到了 20s 左右，感興趣的可以移步我這篇文章：
[項(xiàng)目實(shí)戰(zhàn)] Webpack to Vite， 為開發(fā)提速！
看了一下，線上構(gòu)建時(shí)間五六分鐘，不痛不癢，但是應(yīng)該也有優(yōu)化空間，于是準(zhǔn)備優(yōu)化一下。
1. 發(fā)現(xiàn)問題
既然要優(yōu)化構(gòu)建時(shí)間， 第一步當(dāng)然是先發(fā)現(xiàn)問題， 找出比較耗時(shí)的階段，再加以優(yōu)化。
這里我用到了SMP 插件。
SMP 插件用法非常簡(jiǎn)單， 這里也簡(jiǎn)單提一下：
// webpack.config.js
const SpeedMeasurePlugin = require('speed-measure-webpack-plugin');
const smp = new SpeedMeasurePlugin();
module.exports = smp.wrap({
// ...
});
利用 SMP 插件得出各個(gè)階段的打包耗時(shí)：
發(fā)現(xiàn)兩個(gè)比較明顯的問題：
IgnorePlugin耗時(shí)接近 20 秒。less-loader部分執(zhí)行了2次，浪費(fèi)了一分多鐘。ts-loader耗時(shí)一分半， 也挺長(zhǎng)的。
2. 解決問題
1. IgnorePlugin
查看了一下配置， 發(fā)現(xiàn)配置里的 IgnorePlugin 并沒有達(dá)到預(yù)期的效果， 刪掉。
2. less-loader
查看配置后發(fā)現(xiàn)， 在處理less的部分，確實(shí)多處理了一遍。
less 文件的處理，可以直接看官方文檔，文檔地址：
https://webpack.docschina.org/loaders/less-loader/
我的配置：
{
test: /\.less$/,
use: [
'style-loader',
'css-loader',
{
loader: 'less-loader',
options: {
javascriptEnabled: true,
sourceMap: true,
modifyVars: {
// inject our own global vars
// https://github.com/ant-design/ant-design/issues/16464#issuecomment-491656849
hack: `true;@import '${require.resolve('./src/vars.less')}';`,
...themeVariables,
},
limit: 10000,
name: '[name].[hash:7].[ext]',
outputPath: 'styles/',
},
},
],
},
{
test: /\.css$/,
use: ['style-loader', 'css-loader'],
},
3. ts-loader
對(duì)于ts-loader部分的優(yōu)化， 可以參考：
https://webpack.js.org/guides/build-performance/#typescript-loader
文檔上也有比較清晰的描述：
文檔建議， 我們開啟transpileOnly選項(xiàng)，關(guān)閉類型檢查。
如果要類型檢查， 可以使用 ForkTsCheckerWebpackPlugin，這個(gè)插件會(huì)在另外一個(gè)進(jìn)程中做相關(guān)的檢查。
這個(gè)插件，我們?cè)趦?yōu)化構(gòu)建時(shí)內(nèi)存溢出的問題上， 也做了探索， 感興趣的可以移步我這篇文章：
項(xiàng)目構(gòu)建內(nèi)存溢出了？看看 Node 內(nèi)存限制
現(xiàn)在我們也開啟這個(gè)選項(xiàng)。
開啟之后， 本地構(gòu)建的時(shí)候， 本地報(bào)了個(gè)警告：
這個(gè)錯(cuò)誤， 十分的眼熟， 是之前我們講過的 import type 的問題：
修復(fù)一下：
問題解決。
重新構(gòu)建， 得到如下結(jié)果：
優(yōu)化之后之后， 我們發(fā)現(xiàn)：
IgnorePlugin、HtmlWebpackPlugin時(shí)間大幅縮短。less-loader等恢復(fù)了正常，只執(zhí)行了一次。ts-loader時(shí)間大幅縮短，由1分30秒縮短為40秒。
本地效果明顯，需要去線上構(gòu)建驗(yàn)證。
3. 確認(rèn)有效
在線上執(zhí)行之后， 得到如下結(jié)果：
然后去檢查了一下頁面，也都是正常的。
完美！
回頭看，不難發(fā)現(xiàn)，其實(shí)也沒改多少東西， 就收獲了不錯(cuò)的效果。
針對(duì)中小型項(xiàng)目來說， 改改配置往往就能達(dá)到我們的要求， 但是如果是面對(duì)大型項(xiàng)目呢？
比如那種數(shù)十個(gè)模塊， 幾百個(gè)頁面的項(xiàng)目。
回到開頭那個(gè)問題：修個(gè) bug 1 分鐘， 發(fā)布一下半小時(shí)。
簡(jiǎn)單的修改配置， 都無法把時(shí)間降下來， 這時(shí)候該怎么辦呢？
優(yōu)化大型項(xiàng)目構(gòu)建時(shí)間的一些思考
拆分子應(yīng)用
假設(shè)我們有一個(gè)項(xiàng)目，大模塊就有將近30個(gè)：
每個(gè)大模塊里面又有幾十個(gè)頁面，這種系統(tǒng)構(gòu)建時(shí)間會(huì)比較久， 需要做優(yōu)化。
而且到了項(xiàng)目后期，問題會(huì)越來越明顯, 比如：
代碼越來越臃腫 業(yè)務(wù)模塊本身無關(guān)聯(lián) 構(gòu)建速度越來越慢 無法獨(dú)立部署
面對(duì)這種情況，一種可行的做法是：拆分子應(yīng)用。
拆分之后的架構(gòu)：
每個(gè)子項(xiàng)目都有單獨(dú)的入口， 是可以獨(dú)立部署的項(xiàng)目。
子項(xiàng)目打成單獨(dú)umd包:
在主項(xiàng)目啟動(dòng)的時(shí)候， 再去加載這些子項(xiàng)目：
加載完成之后， 需要處理路由以及store, 示例代碼：
// base
export const bootstrap = () => {
// ...
ReactDOM.render((
<Provider store={store}>
<Router history={history}>
<App defaultInitialData={_initialData} />
</Router>
</Provider>
), document.getElementById('root'));
return Promise.resolve();
};
// main
const loadSubApp = (htmlEntry: string) => {
return importHTML(`${htmlEntry}?${Date.now()}`)
.then((res: any) => res.execScripts())
.then((exportedValues: any) => {
console.log(`importHTML: ${htmlEntry} loaded, exports:`, exportedValues);
const { store, router } = exportedValues || {} as any;
router && addCustomRouter(router);
store && addCustomStore(store);
})
.catch(e => {
console.error('importHTML: ${htmlEntry} load error:', e);
});
};
const load = () => {
if (__ENV__ !== 'dev') {
const paths: string[] = [];
subAppConfig.subApps.forEach(item => {
if (item.project === localStorage.getItem('ops_project')) {
paths.push(...item.paths);
}
});
Promise.all(paths.map(path => loadSubApp(path)))
.catch(e => console.log(e))
.finally(setAllLoaded);
} else {
setAllLoaded();
}
};
const init = () => {
console.log('init: Start to bootstrap the main APP');
addCustomStore(rootStore);
bootstrap().then(() => {
load();
});
};
init();
代碼共享
common包component utils typings .. externalsreact全家桶 moment antd ..
樣式隔離
給樣式添加以子項(xiàng)目為名的 namespace :
開發(fā)調(diào)試
以 ops 項(xiàng)目為例。
讓開發(fā)調(diào)試 ops-common 包像本地文件一樣方便:
讓項(xiàng)目來編譯 common 包
wepback alias
TS alias
獨(dú)立部署
在同一個(gè)project上為每個(gè)子項(xiàng)目申請(qǐng)獨(dú)立module
拆分子應(yīng)用的優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：
每個(gè)子應(yīng)用都可以 獨(dú)立發(fā)布， 子模塊和主模塊解耦。子項(xiàng)目是可以 單獨(dú)編譯的，主項(xiàng)目只需要做引入即可， 以此減少主模塊的構(gòu)建時(shí)間。
缺點(diǎn)：
額外的復(fù)雜性和維護(hù)成本
結(jié)論
一般來說，對(duì)于中小型項(xiàng)目，做好打包配置的優(yōu)化， 能夠解決一部分問題。
大型項(xiàng)目的構(gòu)建時(shí)間優(yōu)化， 可以考慮拆分子應(yīng)用的模式。
只不過這種模式需要考慮一些維護(hù)的問題，比如如何維護(hù)版本 tag、如何快速回滾等。
這些需要結(jié)合你們項(xiàng)目的實(shí)際情況再做決定。
今天的內(nèi)容就這么多，希望對(duì)大家有所啟發(fā)。