【實戰(zhàn)】如何優(yōu)化項目構建時間
背景
前幾天晚上下班的時候， 路過隔壁項目組， 聽他們在聊項目構建的事：
現在線上打包時間太長了， 修個 bug 1 分鐘， 發(fā)布一下半小時, 賊難受。
他們項目比較龐大， 線上構建時間特別長， 基本都在15分鐘以上。
和他們簡單聊了會， 回去瞅了一下自己項目的構建時間：
其實也挺長的， 于是抽空優(yōu)化了一下， 效果還是比較明顯的。
優(yōu)化后：
在正文部分，我將分享的內容主要是：
一些提升 webpack 打包性能的配置優(yōu)化大型項目構建時間的一些思考
希望對大家有所啟發(fā)。
正文
我們項目不是很大, 是一個中型的國際化項目, 一百來個頁面。
之前本地構建時間挺長的，初次啟動要三次分鐘， 后面我配置了 Vite, 本地啟動時間降低到了 20s 左右，感興趣的可以移步我這篇文章：
[項目實戰(zhàn)] Webpack to Vite， 為開發(fā)提速！
看了一下，線上構建時間五六分鐘，不痛不癢，但是應該也有優(yōu)化空間，于是準備優(yōu)化一下。
1. 發(fā)現問題
既然要優(yōu)化構建時間， 第一步當然是先發(fā)現問題， 找出比較耗時的階段，再加以優(yōu)化。
這里我用到了SMP 插件。
SMP 插件用法非常簡單， 這里也簡單提一下：
// webpack.config.js
const SpeedMeasurePlugin = require('speed-measure-webpack-plugin');
const smp = new SpeedMeasurePlugin();
module.exports = smp.wrap({
// ...
});
利用 SMP 插件得出各個階段的打包耗時：
發(fā)現兩個比較明顯的問題：
IgnorePlugin耗時接近 20 秒。less-loader部分執(zhí)行了2次，浪費了一分多鐘。ts-loader耗時一分半， 也挺長的。
2. 解決問題
1. IgnorePlugin
查看了一下配置， 發(fā)現配置里的 IgnorePlugin 并沒有達到預期的效果， 刪掉。
2. less-loader
查看配置后發(fā)現， 在處理less的部分，確實多處理了一遍。
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
對于ts-loader部分的優(yōu)化， 可以參考：
https://webpack.js.org/guides/build-performance/#typescript-loader
文檔上也有比較清晰的描述：
文檔建議， 我們開啟transpileOnly選項，關閉類型檢查。
如果要類型檢查， 可以使用 ForkTsCheckerWebpackPlugin，這個插件會在另外一個進程中做相關的檢查。
這個插件，我們在優(yōu)化構建時內存溢出的問題上， 也做了探索， 感興趣的可以移步我這篇文章：
現在我們也開啟這個選項。
開啟之后， 本地構建的時候， 本地報了個警告：
這個錯誤， 十分的眼熟， 是之前我們講過的 import type 的問題：
修復一下：
問題解決。
重新構建， 得到如下結果：
優(yōu)化之后之后， 我們發(fā)現：
IgnorePlugin、HtmlWebpackPlugin時間大幅縮短。less-loader等恢復了正常，只執(zhí)行了一次。ts-loader時間大幅縮短，由1分30秒縮短為40秒。
本地效果明顯，需要去線上構建驗證。
3. 確認有效
在線上執(zhí)行之后， 得到如下結果：
然后去檢查了一下頁面，也都是正常的。
完美！
回頭看，不難發(fā)現，其實也沒改多少東西， 就收獲了不錯的效果。
針對中小型項目來說， 改改配置往往就能達到我們的要求， 但是如果是面對大型項目呢？
比如那種數十個模塊， 幾百個頁面的項目。
回到開頭那個問題：修個 bug 1 分鐘， 發(fā)布一下半小時。
簡單的修改配置， 都無法把時間降下來， 這時候該怎么辦呢？
優(yōu)化大型項目構建時間的一些思考
拆分子應用
假設我們有一個項目，大模塊就有將近30個：
每個大模塊里面又有幾十個頁面，這種系統(tǒng)構建時間會比較久， 需要做優(yōu)化。
而且到了項目后期，問題會越來越明顯, 比如：
代碼越來越臃腫 業(yè)務模塊本身無關聯 構建速度越來越慢 無法獨立部署
面對這種情況，一種可行的做法是：拆分子應用。
拆分之后的架構：
每個子項目都有單獨的入口， 是可以獨立部署的項目。
子項目打成單獨umd包:
在主項目啟動的時候， 再去加載這些子項目：
加載完成之后， 需要處理路由以及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 ..
樣式隔離
給樣式添加以子項目為名的 namespace :
開發(fā)調試
以 ops 項目為例。
讓開發(fā)調試 ops-common 包像本地文件一樣方便:
讓項目來編譯 common 包
wepback alias
TS alias
獨立部署
在同一個project上為每個子項目申請獨立module
拆分子應用的優(yōu)缺點
優(yōu)點：
每個子應用都可以 獨立發(fā)布， 子模塊和主模塊解耦。子項目是可以 單獨編譯的，主項目只需要做引入即可， 以此減少主模塊的構建時間。
缺點：
額外的復雜性和維護成本
結論
一般來說，對于中小型項目，做好打包配置的優(yōu)化， 能夠解決一部分問題。
大型項目的構建時間優(yōu)化， 可以考慮拆分子應用的模式。
只不過這種模式需要考慮一些維護的問題，比如如何維護版本 tag、如何快速回滾等。
這些需要結合你們項目的實際情況再做決定。
今天的內容就這么多，希望對大家有所啟發(fā)。