基于Rspack實(shí)現(xiàn)大倉應(yīng)用構(gòu)建提效實(shí)踐
一、實(shí)踐背景
隨著項(xiàng)目的逐步迭代，代碼量和依賴的逐漸增長，應(yīng)用的構(gòu)建速度逐步進(jìn)入緩慢期。以目前所在團(tuán)隊(duì)的業(yè)務(wù)應(yīng)用來看（使用webpack構(gòu)建），應(yīng)用整體構(gòu)建耗時已經(jīng)普遍偏高，影響日常開發(fā)測試的使用效率，其中編譯耗時大約占50%。
實(shí)際上隨著近些年前端的技術(shù)發(fā)展以及業(yè)務(wù)對前端交互體驗(yàn)的要求提高，前端整個代碼量復(fù)雜度和代碼量增長飛快。隨著這一趨勢的變化，服務(wù)于前端工程構(gòu)建方案多年的webpack，在構(gòu)建效率上已經(jīng)逐漸成為瓶頸。因此業(yè)界也存在不少優(yōu)化思路和方案，主要分兩個方向：
- 基于原有Node.js語言實(shí)現(xiàn)，通過緩存等方案來提升構(gòu)建效率，主要是緩存、預(yù)構(gòu)建的方式來減少編譯。此類方案多數(shù)存在條件限制，比如緩存方案前提是第一次先生成緩存來提升二次構(gòu)建效率，對于發(fā)布平臺等需要冷啟場景無法生效。
- 另外一類是采用Golang、Rust等語言重新實(shí)現(xiàn)耗時較為復(fù)雜的編譯過程，從語言層面實(shí)現(xiàn)編譯過程的性能提升。比較有代表的有，基于Golang實(shí)現(xiàn)的esbuild、基于Rust實(shí)現(xiàn)的SWC，都在對應(yīng)的場景得到不少的性能提升。
二、業(yè)界方案
既然是業(yè)界的普遍性問題，那么外界也肯定會存在不少優(yōu)化案例可以借鑒或者復(fù)用。由于Node.js的優(yōu)化方案通常都會存在各種場景限制，這里我們主要從另外一個思路去尋找方案。經(jīng)過調(diào)研目前業(yè)界的主要方案有Rspack、Vite、Turbopack、swcpack相對比較有代表性（可能還有其他方案，由于筆者時間精力有限未能了解到）。幾個方案主要的情況如下（筆者個人主觀分析，僅供參考）：
圖片
三、技術(shù)選型
先看當(dāng)前大倉前端應(yīng)用主要技術(shù)體系：整體技術(shù)棧主要是React為主，未來Vue還會逐步遷移React；框架層面UmiJS@4大概占60%、UmiJS@v3大概占20%、剩余為其他Vue或者C端的多頁應(yīng)用。整體技術(shù)體系主要是UmiJS為主，配套主要是webpack的構(gòu)建方案，部分Vue項(xiàng)目有使用Vite。
在這樣的現(xiàn)實(shí)情況下，我們面對的主要是React+UmiJS+webpack的應(yīng)用。基于應(yīng)用廣泛性考慮，只要解決這部分應(yīng)用就可以達(dá)到80%的應(yīng)用提速覆蓋。為此，我們選擇了基于Rspack來實(shí)現(xiàn)構(gòu)建方案的性能提升，主要考慮有以下幾點(diǎn)：
- 高性能：基于Rust實(shí)現(xiàn)核心能力，全量編譯+增量編譯（HMR）的實(shí)現(xiàn)方式，官方宣稱實(shí)際落地有5~10倍的提升，隨著未來逐步優(yōu)化完善還有提升空間，且生產(chǎn)和開發(fā)階段除緩存之外，基本可以獲得一致性的性能收益。
- 低成本：Rspack大量兼容webpack生態(tài)，大量配置和插件可以直接或者調(diào)整一下配置即可復(fù)用，僅需對一些特殊的插件自研定制開發(fā)即可。以下是對項(xiàng)目主要使用到的webpack能力進(jìn)行了梳理，并對其在Rspack中的情況情況也進(jìn)行了對照。
圖片
綜合情況來看：雖然性能Rspack未必是最高的，但其兼容webpack生態(tài)帶來的低成本遷移，是其他的方案基本上無法做到的。對此，選擇了基于Rspack來作為基礎(chǔ)的底層能力。得益于此，我們最終實(shí)現(xiàn)了業(yè)務(wù)代碼零改動即可實(shí)現(xiàn)構(gòu)建方案遷移（僅微調(diào)構(gòu)建配置），并獲得云構(gòu)建2倍+編譯性能的提升。
四、方案設(shè)計(jì)思路
由于大倉目前大量的應(yīng)用為UmiJS@4體系，作為我們主要服務(wù)的目標(biāo)對象，本文也是主要先針對解決UmiJS@4版本的應(yīng)用方案。
方案難點(diǎn)
- UmiJS僅支持webpack和Vite兩種構(gòu)建模式，如何擴(kuò)展Rspack構(gòu)建？
- 業(yè)務(wù)應(yīng)用中有大量使用UmiJS插件、Babel插件來實(shí)現(xiàn)一些特殊能力，如何支持此類插件的能力？
- 如何盡可能降低業(yè)務(wù)應(yīng)用接入成本，進(jìn)而達(dá)成方案快速應(yīng)用到各個業(yè)務(wù)應(yīng)用中？
通過擴(kuò)展插件命令實(shí)現(xiàn)Rspack構(gòu)建
UmiJS默認(rèn)構(gòu)建能力是封裝在@umi/max內(nèi)部，通過max dev/build來調(diào)用內(nèi)置配套的本地/生產(chǎn)構(gòu)建。在UmiJS官方上并未提供編譯能力的完全自定義擴(kuò)展能力，僅支持Vite/webpack的選擇以及提供了一些修改構(gòu)建配置的方法。
通過查看UmiJS項(xiàng)目的源碼，發(fā)現(xiàn)其內(nèi)部的構(gòu)建實(shí)現(xiàn)全部集中在dev/build這兩個擴(kuò)展命令中。源代碼在preset-umi/src/commands/目錄下的dev/dev.ts和build.ts 兩個文件，分別對應(yīng)dev和build命令。而實(shí)際上的構(gòu)建邏輯，實(shí)現(xiàn)上主要是在 @umijs/bundler-vite 和 @umijs/bundler-webpack兩個包中。其內(nèi)部執(zhí)行的主要邏輯如下（這里以dev模式為例，build模式基本上類似，就是少了文件監(jiān)聽編譯和express相關(guān)邏輯）：
圖片
那么我們只需要在新的命令中實(shí)現(xiàn)相關(guān)的邏輯，即可通過擴(kuò)展命令的方式來擴(kuò)展Rspack構(gòu)建能力。另外，使用該方法實(shí)現(xiàn)，還能沿用UmiJS原本的代碼生成等原本的插件，進(jìn)而可以避免需要大量重新實(shí)現(xiàn)UmiJS插件的能力，并降低重寫帶來的邏輯不一致風(fēng)險。
官方平替插件+少部分自研擴(kuò)展支持原有插件能力
前面的插件擴(kuò)展模式已經(jīng)能保證原有大量的UmiJS能力是可以直接沿用的，比如生成路由、添加tailwind.css等UmiJS內(nèi)置能力都可直接沿用。另外項(xiàng)目主要依賴擴(kuò)展的插件，除了少部分修改構(gòu)建能力的插件之外，基本上都可以直接使用或者少量適配即可。不兼容的幾個插件主要是因?yàn)椋汗δ苁峭ㄟ^修改的webpack配置來調(diào)整構(gòu)建能力，需要通過使用對應(yīng)的Rspack構(gòu)建能力來進(jìn)行兼容。
另外除了UmiJS的插件之外，還有構(gòu)建依賴的Babel插件部分，當(dāng)然部分Babel插件也是通過UmiJS插件引入使用的。對此，也對主要的Babel插件的情況進(jìn)行了梳理，其主要的情況如下表：
圖片
所以整體上還是以沿用webpack原有擴(kuò)展加Rspack官方能力替換為主，只需要針對少部分未支持的Babel插件進(jìn)行擴(kuò)展即可實(shí)現(xiàn)。
基于配置映射實(shí)現(xiàn)業(yè)務(wù)超低接入成本
想要達(dá)成方案可以快速應(yīng)用的理想效果，就是讓應(yīng)用接入過程中盡可能少改內(nèi)容，特別是業(yè)務(wù)代碼。因?yàn)橐坏┮臉I(yè)務(wù)代碼邏輯，這種就會增加非常多的接入成本，所以在方案設(shè)計(jì)上，構(gòu)建能力以及原本UmiJS的相關(guān)配置能力要盡量去沿用并且滿足基本上不需要業(yè)務(wù)側(cè)同學(xué)去感知差異化的內(nèi)容。
帶著這個需求并結(jié)合前面的幾塊內(nèi)容分析來看，大多數(shù)內(nèi)容都是有平替方案，少部分需要進(jìn)行自定義開發(fā)擴(kuò)展，主要也是集中在Babel插件上。那么我們需要做的就是維持UmiJS轉(zhuǎn)換生成webpack的配置邏輯不動，在拿到webpack配置之后，再對webpack的配置做解析通過一個配置轉(zhuǎn)換器對需要轉(zhuǎn)換成Rspack的內(nèi)容進(jìn)行轉(zhuǎn)化，對原本兼容的配置直接遷移使用即可實(shí)現(xiàn)我們的目的。
配置&能力映射示意圖：
圖片
方案架構(gòu)
結(jié)合以上的問題解決思路以及目標(biāo)，最終方案的架構(gòu)設(shè)計(jì)如下：
架構(gòu)要點(diǎn)說明：
- 通過擴(kuò)展自研插件，提供自定義的rspack-dev和rspack-build命令來提供開發(fā)、生產(chǎn)模式，接入時僅需要安裝插件并替換啟動命令即可（舉個例子：package.json中修改max dev為max rspack-dev）。
- 通過插件內(nèi)部對配置進(jìn)行轉(zhuǎn)化，將原本UmiJS的配置轉(zhuǎn)為Rspack配置，保障業(yè)務(wù)應(yīng)用接入時基本不感知。另外在開發(fā)成本方面，由于大多數(shù)loader和plugin可以復(fù)用，主要是配置和loader等能力替換映射成本。
- 方案基于UmiJS的max擴(kuò)展，原本UmiJS的擴(kuò)展能力不受影響。業(yè)務(wù)高使用率Babel插件有現(xiàn)成的SWC擴(kuò)展能力可直接替換（比如：Babel-plugin-import、svgr等），少部分自研插件需要使用Rust重寫。
穩(wěn)定性保障
切換構(gòu)建之后，less/postcss插件是一致的，主要風(fēng)險來自于兩個方面：
- webpack轉(zhuǎn)Rspack：Rspack項(xiàng)目內(nèi)平移了大量的webpack測試用例用于保障一致性，另外默認(rèn)嚴(yán)格模式，出現(xiàn)不兼容配置會拋出錯誤中斷構(gòu)建，保證了基礎(chǔ)方面的穩(wěn)定性。
圖片
- Babel（v7）轉(zhuǎn)SWC：SWC支持所有stage 3 perposals 、preset-env，JS/TS語法編譯能力上跟Babel 7對齊。在插件生態(tài)上不一致，若有使用Babel插件，需要考慮替換方案（詳情參考前文中的Babel插件使用情況）。
圖片
雖然在Rspack方面申明已經(jīng)兼容了主流的內(nèi)容，但畢竟是替換了構(gòu)建方案，對業(yè)務(wù)來說還是存在一些未知的風(fēng)險，還是需要一些手段來進(jìn)行保障業(yè)務(wù)應(yīng)用的穩(wěn)定性。
穩(wěn)定性保障手段：
- 構(gòu)建報(bào)錯中斷策略：配置上出現(xiàn)不支持的Babel插件直接報(bào)錯中斷構(gòu)建，避免未支持的內(nèi)容被跳過進(jìn)而導(dǎo)致異常發(fā)布上線。
- 階段推進(jìn)落地策略：由于大多數(shù)構(gòu)建運(yùn)行都是在開發(fā)測試階段（粗略統(tǒng)計(jì)平臺發(fā)布70%左右為測試環(huán)境），先行接入開發(fā)&測試環(huán)境達(dá)到構(gòu)建效率提升，等開發(fā)測試階段跑穩(wěn)定之后，再從非核心應(yīng)用開始試點(diǎn)上線，功能穩(wěn)定之后再逐步推廣。
- 極簡的應(yīng)急恢復(fù)策略：由于極低的接入成本，若接入遇到問題想快速回退也非常簡單，僅需回退命令為dev/build即可完成應(yīng)急恢復(fù)。
五、方案效益
實(shí)現(xiàn)超低接入成本：僅需改動三個小步驟，一兩分鐘即可完成接入。具體步驟如下：
- 添加并安裝依賴：添加并安裝@umijs/plugin-rspack依賴（得物私有npm包）。
dx add @umijs/plugin-rspack@latest -D- 添加UmiJS的plugin：在config/config.ts中修改plugins屬性。
{
// 原有其他配置
...
plugins: [
// 原有其他插件
...,
// 添加 @umijs/plugin-rspack 插件
'@umijs/plugin-rspack',
],
// 原有其他配置
...
}- 修改構(gòu)建命令：修改package.json中的構(gòu)建命令，將對應(yīng)環(huán)境的命令調(diào)整為rspack-dev/rspack-build，并增加NODE_ENV配置。
{
"scripts": {
// start 對應(yīng)支持本地的dx dev，
// 原配置樣例
- "start": "cross-env BUILD_ENV=dev max dev",
// 改rspack構(gòu)建樣例
+ "start": "cross-env BUILD_ENV=dev NODE_ENV=development max rspack-dev",
// pnpm:build:x 對應(yīng)支持發(fā)布平臺指定的環(huán)境
// 原t1配置樣例
- "pnpm:build:t1": "cross-env BUILD_ENV=t1 max build",
// t1改rspack構(gòu)建樣例
+ "pnpm:build:t1": "cross-env BUILD_ENV=t1 NODE_ENV=production max rspack-build",
... // 原先的其他配置，酌情進(jìn)行調(diào)整
}
}平均2倍+的編譯性能提升：大倉應(yīng)用接入17個應(yīng)用（目前主要是接入開發(fā)、測試環(huán)境），平均提升在2倍以上。以自身負(fù)責(zé)的一個應(yīng)用為例，原有webpack編譯耗時150秒，接入后降低到40秒（減少73.33%），加上優(yōu)化過程中去除部分無用的引入代碼最終僅需20秒左右。
六、分享過程中的一些干貨
這里主要結(jié)合UmiJS所需要的能力，分享一些UmiJS涉及到的Rspack用法以及過程中一些比較典型的內(nèi)容。
支持ts/tsx
ts/tsx的支持主要依靠的是swc-loader，Rspack使用了Rust定制的builtin:swc-loader，其使用方式基本上是跟webpack的swc-loader一致的，詳情可以直接參考swc-loader文檔，這里主要體現(xiàn)一些常用的配置項(xiàng)，具體使用可以結(jié)合自身項(xiàng)目情況來調(diào)整。
export default {
module: {
rules: [
{
test: /\.(j|t)s(x)?$/,
loader: 'builtin:swc-loader',
options: {
env: {
// 瀏覽器兼容性，支持browserslist，詳細(xì)可以參考：https://swc.rs/docs/configuration/supported-browsers#targets
targets: {
chrome: "80",
},
},
// js/ts編譯配置
jsc: {
parser: {
// 開啟ts編譯
syntax: 'typescript',
// 開啟tsx編譯
tsx: true,
// 開啟@裝飾器編譯
decorators: true,
// 動態(tài)import
// dynamicImport: false,
},
transform: {
// react運(yùn)行環(huán)境配置
react: {
// dev模式打開development啟動react的開發(fā)模式
development: isDev,
},
// stage 1 的舊版本class decorators
legacyDecorator: true,
// 支持 ts emitDecoratorMetadata
decoratorMetadata: true,
},
},
},
},
]
}
}React HMR
在看文檔配置時，感覺不好理解，實(shí)際使用上其實(shí)分兩種情況：
- 直接使用Rspack的devServer情況下，需要同時開啟devServer.hot和@rspack/plugin-react-refresh。如下配置：
import ReactRefreshPlugin from '@rspack/plugin-react-refresh';
export default {
... 其他配置
devServer: {
// 開啟HMR，官方文檔也有體現(xiàn)
hot: true,
},
plugins: [
...其他插件
// React熱更新支持插件
isDev && new ReactRefreshPlugin(),
]
}- 若不使用devServer的情況下，需要用rspack.HotModuleReplacementPlugin來實(shí)現(xiàn)devServer.hot的能力。由于這種方式未在實(shí)踐過程中進(jìn)應(yīng)用，這里不進(jìn)行具體的使用舉例。
Module Federation
Rspack提供了兩個版本的模塊聯(lián)邦能力，官方文檔主要是介紹的v1.5對應(yīng)的是經(jīng)過Rspack改良過的版本。但實(shí)際上在一些情況下，如果直接跟webpack的MF對接會存在一些問題。我們在第一次使用過程中，也是對接了默認(rèn)的v1.5版本，就出現(xiàn)了公共依賴無法找到的問題，錯誤提示如下：
圖片
實(shí)際上若需要跟webpack項(xiàng)目對接的情況下，需要采用v1.0版本的MF插件，使用方法如下：
import { container } from '@rspack/core';
export default {
... 其他配置
plugins: [
new container.ModuleFederationPluginV1({
... 這里是mf的配置
})
]
}樣式按需引入：babel-plugin-import
babel-plugin-import作用：主要是配合ant-design或poizon-design（基于antd定制主題）庫來使用，通過插件識別js中依賴的組件，自動注入樣式文件，進(jìn)而實(shí)現(xiàn)css的按需引用。實(shí)現(xiàn)類似如下效果：
// 手寫源代碼
import { Button, Input } from 'antd';
// 通過插件編譯后
import { Button, Input } from 'antd';
import 'antd/lib/button/style';
import 'antd/lib/input/style';在Rspack中使用的是swc來進(jìn)行js/ts解析的，故babel-plugin-import是不能直接使用的，需要采用builtin:swc-loader的rspackExperiments來進(jìn)行對應(yīng)的能力支持。其配置方法如下：
export default {
module: {
rules: [
{
test: /\.(j|t)s(x)?$/,
loader: 'builtin:swc-loader',
options: {
experimental: {
// babel-plugin-import的配置
import: [
// pd按需注入樣式
{ libraryName: 'poizon-design', libraryDirectory: 'es', style: true },
// antd按需注入樣式
{ libraryName: 'antd', libraryDirectory: 'es', style: true },
],
}
}
}
]
}
}cssModules：auto-css-modules
在UmiJS中，默認(rèn)是通過auto-css-modules來進(jìn)行css-modules代碼的判斷；其原理為通過ast語法樹，判斷import引入樣式文件時，若有聲明對應(yīng)的變量，就將其打上一個query標(biāo)記。并在樣式文件處理時，通過resourceQuery來進(jìn)行匹配對應(yīng)的文件，并添加css-modules的編譯能力。詳情見：UmiJS AutoCssModules插件源代碼、UmiJS CSS編譯配置源代碼。
通過UmiJS項(xiàng)目以及結(jié)合一些資料，Babel的auto-css-modules能力有swc-plugin-auto-css-modules可以替代，配置的話，主要幾個關(guān)鍵點(diǎn)：
- 添加swc-plugin-auto-css-modules插件（實(shí)際上開源的插件并不能用，后文詳細(xì)說明原因）。
- 添加builtins.css配置，指定cssModules編譯時的方式，主要有樣式名是否保持，輸出的樣式格式。
- 添加resourceQuery識別，并給對應(yīng)的內(nèi)容加type: 'css/module'；Rspack默認(rèn)會對type: 'css/module'的代碼當(dāng)做cssModules編譯，這個用法會比使用css-loader+style-loader更方便。
具體配置實(shí)現(xiàn)參考如下：
const postcssLoader = {
loader: require.resolve('postcss-loader'),
options: {
// ...此處省略less-loader配置
}
};
const lessLoader = {
loader: require.resolve('less-loader'),
options: {
// ...此處省略less-loader配置
}
}
export default {
builtins: {
css: {
// cssModule默認(rèn)配置
modules: {
// class保持原樣輸出
localsConvention: 'asIs',
// class轉(zhuǎn)換后的格式，localIdentName跟css-loader并不完全兼容，比如[hash:base64:5]這種寫法就會報(bào)錯
localIdentName: '[local]_[hash:8]',
},
},
},
module: {
rules: [
{
test: /\.(j|t)s(x)?$/,
loader: 'builtin:swc-loader',
options: {
experimental: {
plugins: [
// ...此處其他配置內(nèi)容
// 添加 swc-plugin-auto-css-modules 插件執(zhí)行?modules的注入
[require.resolve('swc-plugin-auto-css-modules'), {}]
]
}
},
},
{
test: /\.css(\?.*)?$/,
oneOf: [
{
// 通過resourceQuery來匹配?modules
resourceQuery: /modules/,
use: [postcssLoader],
// type聲明指定為cssModules解析
type: 'css/module'
},
{
use: [postcssLoader],
// type聲明指定為普通css解析
type: 'css'
},
]
},
{
test: /\.less(\?.*)?$/,
oneOf: [
{
resourceQuery: /modules/,
use: [postcssLoader, lessLoader],
type: 'css/module'
},
{
use: [postcssLoader, lessLoader],
type: 'css'
},
]
},
]
}
}但實(shí)際上上述的配置并不能直接跑起來，運(yùn)行時會提示構(gòu)建報(bào)錯（RuntimeError: out of bounds memory accesSS），錯誤如下圖：
圖片
結(jié)合github上的相關(guān)issue最終定位為swc_core版本不兼容的問題導(dǎo)致。
原因詳解：
- Rspack使用的swc_core為0.88.x~0.89.x對應(yīng)@swc/core為@swc/core@1.3.106~@swc/core@1.3.107(swc官網(wǎng)可見)。
- swc-plugin-auto-css-modules的@1.6.0雖然在文檔上寫著是兼容>= 1.3.106版本，但實(shí)際上由于其內(nèi)部使用了swc_core@0.90.13（詳見Github源碼）。
- 但swc在0.90.x進(jìn)行了ast的重構(gòu)，跟之前的版本有了較大出入，導(dǎo)致無法生成的wasm調(diào)用無法兼容。
問題解決辦法：實(shí)際上只要通過將swc-plugin-auto-css-modules的swc_core版本修改為0.88.x~0.89.x這個范圍內(nèi)，再編譯出新的wasm文件即可解決；若有其他類似情況，也可以借鑒一下。
具體操作步驟：
- 將swc-plugin-auto-css-modules的swc_core修改版本后，在本地構(gòu)建生成一個wasm文件，并放到項(xiàng)目內(nèi)。
- swc的plugin修改為引入本地構(gòu)建的wasm文件，其配置如下。
plugins: [
// ...此處其他配置內(nèi)容
// 添加 swc-plugin-auto-css-modules 插件執(zhí)行?modules的注入
// 刪掉原有的 swc-plugin-auto-css-modules 引入
- [require.resolve('swc-plugin-auto-css-modules'), {}]
// 修改為引入項(xiàng)目相對目錄下的swc_plugin_auto_css_modules.wasm（因?yàn)殚_源的發(fā)版有發(fā)版周期，先進(jìn)行自編譯使用）
+ [path.join(__dirname, '../../swc-plugins/swc_plugin_auto_css_modules.wasm'), {}],
]影響編譯效率的devtool: "source-map"
在以往使用webpack的devtool時，也能感受到有一定的性能開銷；同時在Rspack中，官方文檔中也有說明當(dāng)devtool開啟并設(shè)置sourcemap時有性能開銷。官方文檔：
圖片
實(shí)際體驗(yàn)下來，source-map的模式損耗確實(shí)是大，大約會增加30%的耗時，而其他一些模式在構(gòu)建損耗上會有所優(yōu)化，具體可視使用情況來選擇建議在開發(fā)測試環(huán)境不使用，僅在線上等需要的環(huán)境開啟。相同應(yīng)用和機(jī)器環(huán)境，不同devtool的幾種測試表現(xiàn)如下：
devtool: source-map（40.82s）
devtool: cheap-module-source-map（39.46s）
devtool: eval（32.94s）
devtool: false (31.21s)
可能你不知道的低效代碼
在前面的內(nèi)容中有提到babel-plugin-import按需引入的利器，但在業(yè)務(wù)項(xiàng)目中也有發(fā)現(xiàn)，應(yīng)用/組件中有直接引入.../dist/antd.less的情況。若在項(xiàng)目中有這種情況，實(shí)際上就是打包了多次antd的樣式，非但沒有作用反而讓構(gòu)建打包和應(yīng)用訪問性能更差。
以下為英特爾i5芯片差異情況（M2等芯片在耗時上會縮小一些）：
在css-moduels中（比如：大多數(shù)頁面less、組件less）：每引入一次，大約增加6~7s左右構(gòu)建時間，css文件大約增加660kb。
在非css-moduels中（比如：global.less）：每引入一次，大約增加4~5s構(gòu)建時間，css文件大約增加530kb。
??????：建議平時項(xiàng)目中排查注意一下，可以將此類代碼進(jìn)行刪除，一個小小的習(xí)慣就可以直接提升不小的構(gòu)建和訪問性能。
七、未來規(guī)劃
整個項(xiàng)目過程下來，收獲頗豐。一個是對前端構(gòu)建以及Rust方面有了更多的認(rèn)識，另外在接入過程中，也對當(dāng)前的應(yīng)用現(xiàn)狀和技術(shù)體系由了更深入的了解。但當(dāng)前項(xiàng)目主要服務(wù)于自身的業(yè)務(wù)的開發(fā)測試環(huán)境，使用范圍還相對比較窄，還存在一些轉(zhuǎn)換能力缺失的情況。未來將持續(xù)完善現(xiàn)有的構(gòu)建轉(zhuǎn)換能力，來拓展更多的業(yè)務(wù)應(yīng)用場景。
八、特別說明
由于文章內(nèi)的相關(guān)內(nèi)容實(shí)踐已經(jīng)落地有了一段時間，文章內(nèi)的一些內(nèi)容可能已經(jīng)發(fā)生了變化，若存在出入煩請以相應(yīng)產(chǎn)品的官方介紹為準(zhǔn)。比如：Rspack的新版本已經(jīng)升級了swc_core到v0.91.x~v0.93.x兼容了swc-plugin-auto-css-modules的1.6.0版本，Turbopack計(jì)劃未來全面支持webpack的相關(guān)工具特性等。
相關(guān)參考資料站點(diǎn)：
- Rspack：https://www.rspack.dev/
- UmiJS: https://umijs.org/
- Webpack：https://webpack.js.org/
- SWC：https://swc.rs/
- Vite：https://cn.vitejs.dev/guide/
- Turbopack：https://turbo.build/pack
