一、實(shí)踐背景

隨著項(xiàng)目的逐步迭代，代碼量和依賴的逐漸增長(zhǎng)，應(yīng)用的構(gòu)建速度逐步進(jìn)入緩慢期。以目前所在團(tuán)隊(duì)的業(yè)務(wù)應(yīng)用來(lái)看（使用webpack構(gòu)建），應(yīng)用整體構(gòu)建耗時(shí)已經(jīng)普遍偏高，影響日常開發(fā)測(cè)試的使用效率，其中編譯耗時(shí)大約占50%。

實(shí)際上隨著近些年前端的技術(shù)發(fā)展以及業(yè)務(wù)對(duì)前端交互體驗(yàn)的要求提高，前端整個(gè)代碼量復(fù)雜度和代碼量增長(zhǎng)飛快。隨著這一趨勢(shì)的變化，服務(wù)于前端工程構(gòu)建方案多年的webpack，在構(gòu)建效率上已經(jīng)逐漸成為瓶頸。因此業(yè)界也存在不少優(yōu)化思路和方案，主要分兩個(gè)方向：

• 基于原有Node.js語(yǔ)言實(shí)現(xiàn)，通過(guò)緩存等方案來(lái)提升構(gòu)建效率，主要是緩存、預(yù)構(gòu)建的方式來(lái)減少編譯。此類方案多數(shù)存在條件限制，比如緩存方案前提是第一次先生成緩存來(lái)提升二次構(gòu)建效率，對(duì)于發(fā)布平臺(tái)等需要冷啟場(chǎng)景無(wú)法生效。
• 另外一類是采用Golang、Rust等語(yǔ)言重新實(shí)現(xiàn)耗時(shí)較為復(fù)雜的編譯過(guò)程，從語(yǔ)言層面實(shí)現(xiàn)編譯過(guò)程的性能提升。比較有代表的有，基于Golang實(shí)現(xiàn)的esbuild、基于Rust實(shí)現(xiàn)的SWC，都在對(duì)應(yīng)的場(chǎng)景得到不少的性能提升。

二、業(yè)界方案

既然是業(yè)界的普遍性問(wèn)題，那么外界也肯定會(huì)存在不少優(yōu)化案例可以借鑒或者復(fù)用。由于Node.js的優(yōu)化方案通常都會(huì)存在各種場(chǎng)景限制，這里我們主要從另外一個(gè)思路去尋找方案。經(jīng)過(guò)調(diào)研目前業(yè)界的主要方案有Rspack、Vite、Turbopack、swcpack相對(duì)比較有代表性（可能還有其他方案，由于筆者時(shí)間精力有限未能了解到）。幾個(gè)方案主要的情況如下（筆者個(gè)人主觀分析，僅供參考）：

圖片

三、技術(shù)選型

先看當(dāng)前大倉(cāng)前端應(yīng)用主要技術(shù)體系：整體技術(shù)棧主要是React為主，未來(lái)Vue還會(huì)逐步遷移React；框架層面UmiJS@4大概占60%、UmiJS@v3大概占20%、剩余為其他Vue或者C端的多頁(yè)應(yīng)用。整體技術(shù)體系主要是UmiJS為主，配套主要是webpack的構(gòu)建方案，部分Vue項(xiàng)目有使用Vite。

在這樣的現(xiàn)實(shí)情況下，我們面對(duì)的主要是React+UmiJS+webpack的應(yīng)用?；趹?yīng)用廣泛性考慮，只要解決這部分應(yīng)用就可以達(dá)到80%的應(yīng)用提速覆蓋。為此，我們選擇了基于Rspack來(lái)實(shí)現(xiàn)構(gòu)建方案的性能提升，主要考慮有以下幾點(diǎn)：

• 高性能：基于Rust實(shí)現(xiàn)核心能力，全量編譯+增量編譯（HMR）的實(shí)現(xiàn)方式，官方宣稱實(shí)際落地有5~10倍的提升，隨著未來(lái)逐步優(yōu)化完善還有提升空間，且生產(chǎn)和開發(fā)階段除緩存之外，基本可以獲得一致性的性能收益。
• 低成本：Rspack大量兼容webpack生態(tài)，大量配置和插件可以直接或者調(diào)整一下配置即可復(fù)用，僅需對(duì)一些特殊的插件自研定制開發(fā)即可。以下是對(duì)項(xiàng)目主要使用到的webpack能力進(jìn)行了梳理，并對(duì)其在Rspack中的情況情況也進(jìn)行了對(duì)照。

圖片

綜合情況來(lái)看：雖然性能Rspack未必是最高的，但其兼容webpack生態(tài)帶來(lái)的低成本遷移，是其他的方案基本上無(wú)法做到的。對(duì)此，選擇了基于Rspack來(lái)作為基礎(chǔ)的底層能力。得益于此，我們最終實(shí)現(xiàn)了業(yè)務(wù)代碼零改動(dòng)即可實(shí)現(xiàn)構(gòu)建方案遷移（僅微調(diào)構(gòu)建配置），并獲得云構(gòu)建2倍+編譯性能的提升。

四、方案設(shè)計(jì)思路

由于大倉(cāng)目前大量的應(yīng)用為UmiJS@4體系，作為我們主要服務(wù)的目標(biāo)對(duì)象，本文也是主要先針對(duì)解決UmiJS@4版本的應(yīng)用方案。

方案難點(diǎn)

• UmiJS僅支持webpack和Vite兩種構(gòu)建模式，如何擴(kuò)展Rspack構(gòu)建？
• 業(yè)務(wù)應(yīng)用中有大量使用UmiJS插件、Babel插件來(lái)實(shí)現(xiàn)一些特殊能力，如何支持此類插件的能力？
• 如何盡可能降低業(yè)務(wù)應(yīng)用接入成本，進(jìn)而達(dá)成方案快速應(yīng)用到各個(gè)業(yè)務(wù)應(yīng)用中？

通過(guò)擴(kuò)展插件命令實(shí)現(xiàn)Rspack構(gòu)建

UmiJS默認(rèn)構(gòu)建能力是封裝在@umi/max內(nèi)部，通過(guò)max dev/build來(lái)調(diào)用內(nèi)置配套的本地/生產(chǎn)構(gòu)建。在UmiJS官方上并未提供編譯能力的完全自定義擴(kuò)展能力，僅支持Vite/webpack的選擇以及提供了一些修改構(gòu)建配置的方法。

通過(guò)查看UmiJS項(xiàng)目的源碼，發(fā)現(xiàn)其內(nèi)部的構(gòu)建實(shí)現(xiàn)全部集中在dev/build這兩個(gè)擴(kuò)展命令中。源代碼在preset-umi/src/commands/目錄下的dev/dev.ts和build.ts 兩個(gè)文件，分別對(duì)應(yīng)dev和build命令。而實(shí)際上的構(gòu)建邏輯，實(shí)現(xiàn)上主要是在 @umijs/bundler-vite 和 @umijs/bundler-webpack兩個(gè)包中。其內(nèi)部執(zhí)行的主要邏輯如下（這里以dev模式為例，build模式基本上類似，就是少了文件監(jiān)聽編譯和express相關(guān)邏輯）：

圖片

那么我們只需要在新的命令中實(shí)現(xiàn)相關(guān)的邏輯，即可通過(guò)擴(kuò)展命令的方式來(lái)擴(kuò)展Rspack構(gòu)建能力。另外，使用該方法實(shí)現(xiàn)，還能沿用UmiJS原本的代碼生成等原本的插件，進(jìn)而可以避免需要大量重新實(shí)現(xiàn)UmiJS插件的能力，并降低重寫帶來(lái)的邏輯不一致風(fēng)險(xiǎn)。

官方平替插件+少部分自研擴(kuò)展支持原有插件能力

前面的插件擴(kuò)展模式已經(jīng)能保證原有大量的UmiJS能力是可以直接沿用的，比如生成路由、添加tailwind.css等UmiJS內(nèi)置能力都可直接沿用。另外項(xiàng)目主要依賴擴(kuò)展的插件，除了少部分修改構(gòu)建能力的插件之外，基本上都可以直接使用或者少量適配即可。不兼容的幾個(gè)插件主要是因?yàn)椋汗δ苁峭ㄟ^(guò)修改的webpack配置來(lái)調(diào)整構(gòu)建能力，需要通過(guò)使用對(duì)應(yīng)的Rspack構(gòu)建能力來(lái)進(jìn)行兼容。

另外除了UmiJS的插件之外，還有構(gòu)建依賴的Babel插件部分，當(dāng)然部分Babel插件也是通過(guò)UmiJS插件引入使用的。對(duì)此，也對(duì)主要的Babel插件的情況進(jìn)行了梳理，其主要的情況如下表：

圖片

所以整體上還是以沿用webpack原有擴(kuò)展加Rspack官方能力替換為主，只需要針對(duì)少部分未支持的Babel插件進(jìn)行擴(kuò)展即可實(shí)現(xiàn)。

基于配置映射實(shí)現(xiàn)業(yè)務(wù)超低接入成本

想要達(dá)成方案可以快速應(yīng)用的理想效果，就是讓應(yīng)用接入過(guò)程中盡可能少改內(nèi)容，特別是業(yè)務(wù)代碼。因?yàn)橐坏┮臉I(yè)務(wù)代碼邏輯，這種就會(huì)增加非常多的接入成本，所以在方案設(shè)計(jì)上，構(gòu)建能力以及原本UmiJS的相關(guān)配置能力要盡量去沿用并且滿足基本上不需要業(yè)務(wù)側(cè)同學(xué)去感知差異化的內(nèi)容。

帶著這個(gè)需求并結(jié)合前面的幾塊內(nèi)容分析來(lái)看，大多數(shù)內(nèi)容都是有平替方案，少部分需要進(jìn)行自定義開發(fā)擴(kuò)展，主要也是集中在Babel插件上。那么我們需要做的就是維持UmiJS轉(zhuǎn)換生成webpack的配置邏輯不動(dòng)，在拿到webpack配置之后，再對(duì)webpack的配置做解析通過(guò)一個(gè)配置轉(zhuǎn)換器對(duì)需要轉(zhuǎn)換成Rspack的內(nèi)容進(jìn)行轉(zhuǎn)化，對(duì)原本兼容的配置直接遷移使用即可實(shí)現(xiàn)我們的目的。

配置&能力映射示意圖：

圖片

方案架構(gòu)

結(jié)合以上的問(wèn)題解決思路以及目標(biāo)，最終方案的架構(gòu)設(shè)計(jì)如下：

架構(gòu)要點(diǎn)說(shuō)明：

• 通過(guò)擴(kuò)展自研插件，提供自定義的rspack-dev和rspack-build命令來(lái)提供開發(fā)、生產(chǎn)模式，接入時(shí)僅需要安裝插件并替換啟動(dòng)命令即可（舉個(gè)例子：package.json中修改max dev為max rspack-dev）。
• 通過(guò)插件內(nèi)部對(duì)配置進(jìn)行轉(zhuǎn)化，將原本UmiJS的配置轉(zhuǎn)為Rspack配置，保障業(yè)務(wù)應(yīng)用接入時(shí)基本不感知。另外在開發(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)險(xiǎn)來(lái)自于兩個(gè)方面：

• webpack轉(zhuǎn)Rspack：Rspack項(xiàng)目?jī)?nèi)平移了大量的webpack測(cè)試用例用于保障一致性，另外默認(rèn)嚴(yán)格模式，出現(xiàn)不兼容配置會(huì)拋出錯(cuò)誤中斷構(gòu)建，保證了基礎(chǔ)方面的穩(wěn)定性。

圖片

• Babel（v7）轉(zhuǎn)SWC：SWC支持所有stage 3 perposals 、preset-env，JS/TS語(yǔ)法編譯能力上跟Babel 7對(duì)齊。在插件生態(tài)上不一致，若有使用Babel插件，需要考慮替換方案（詳情參考前文中的Babel插件使用情況）。

圖片

雖然在Rspack方面申明已經(jīng)兼容了主流的內(nèi)容，但畢竟是替換了構(gòu)建方案，對(duì)業(yè)務(wù)來(lái)說(shuō)還是存在一些未知的風(fēng)險(xiǎn)，還是需要一些手段來(lái)進(jìn)行保障業(yè)務(wù)應(yīng)用的穩(wěn)定性。

穩(wěn)定性保障手段：

• 構(gòu)建報(bào)錯(cuò)中斷策略：配置上出現(xiàn)不支持的Babel插件直接報(bào)錯(cuò)中斷構(gòu)建，避免未支持的內(nèi)容被跳過(guò)進(jìn)而導(dǎo)致異常發(fā)布上線。
• 階段推進(jìn)落地策略：由于大多數(shù)構(gòu)建運(yùn)行都是在開發(fā)測(cè)試階段（粗略統(tǒng)計(jì)平臺(tái)發(fā)布70%左右為測(cè)試環(huán)境），先行接入開發(fā)&測(cè)試環(huán)境達(dá)到構(gòu)建效率提升，等開發(fā)測(cè)試階段跑穩(wěn)定之后，再?gòu)姆呛诵膽?yīng)用開始試點(diǎn)上線，功能穩(wěn)定之后再逐步推廣。
• 極簡(jiǎn)的應(yīng)急恢復(fù)策略：由于極低的接入成本，若接入遇到問(wèn)題想快速回退也非常簡(jiǎn)單，僅需回退命令為dev/build即可完成應(yīng)急恢復(fù)。

五、方案效益

實(shí)現(xiàn)超低接入成本：僅需改動(dòng)三個(gè)小步驟，一兩分鐘即可完成接入。具體步驟如下：

• 添加并安裝依賴：添加并安裝@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)建命令，將對(duì)應(yīng)環(huán)境的命令調(diào)整為rspack-dev/rspack-build，并增加NODE_ENV配置。

{
    "scripts": {
        // start 對(duì)應(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 對(duì)應(yīng)支持發(fā)布平臺(tái)指定的環(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倍+的編譯性能提升：大倉(cāng)應(yīng)用接入17個(gè)應(yīng)用（目前主要是接入開發(fā)、測(cè)試環(huán)境），平均提升在2倍以上。以自身負(fù)責(zé)的一個(gè)應(yīng)用為例，原有webpack編譯耗時(shí)150秒，接入后降低到40秒（減少73.33%），加上優(yōu)化過(guò)程中去除部分無(wú)用的引入代碼最終僅需20秒左右。

六、分享過(guò)程中的一些干貨

這里主要結(jié)合UmiJS所需要的能力，分享一些UmiJS涉及到的Rspack用法以及過(guò)程中一些比較典型的內(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)目情況來(lái)調(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,
              // 動(dòng)態(tài)import
              // dynamicImport: false,
            },
            transform: {
              // react運(yùn)行環(huán)境配置
              react: {
                // dev模式打開development啟動(dòng)react的開發(fā)模式
                development: isDev,
              },
              // stage 1 的舊版本class decorators
              legacyDecorator: true,
              // 支持 ts emitDecoratorMetadata
              decoratorMetadata: true,
            },
          },
        },
      },
    ]
  }
}

React HMR

在看文檔配置時(shí)，感覺不好理解，實(shí)際使用上其實(shí)分兩種情況：

• 直接使用Rspack的devServer情況下，需要同時(shí)開啟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來(lái)實(shí)現(xiàn)devServer.hot的能力。由于這種方式未在實(shí)踐過(guò)程中進(jìn)應(yīng)用，這里不進(jìn)行具體的使用舉例。

Module Federation

Rspack提供了兩個(gè)版本的模塊聯(lián)邦能力，官方文檔主要是介紹的v1.5對(duì)應(yīng)的是經(jīng)過(guò)Rspack改良過(guò)的版本。但實(shí)際上在一些情況下，如果直接跟webpack的MF對(duì)接會(huì)存在一些問(wèn)題。我們?cè)诘谝淮问褂眠^(guò)程中，也是對(duì)接了默認(rèn)的v1.5版本，就出現(xiàn)了公共依賴無(wú)法找到的問(wèn)題，錯(cuò)誤提示如下：

圖片

實(shí)際上若需要跟webpack項(xiàng)目對(duì)接的情況下，需要采用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定制主題）庫(kù)來(lái)使用，通過(guò)插件識(shí)別js中依賴的組件，自動(dòng)注入樣式文件，進(jìn)而實(shí)現(xiàn)css的按需引用。實(shí)現(xiàn)類似如下效果：

// 手寫源代碼
import { Button, Input } from 'antd';


// 通過(guò)插件編譯后
import { Button, Input } from 'antd';
import 'antd/lib/button/style';
import 'antd/lib/input/style';

在Rspack中使用的是swc來(lái)進(jìn)行js/ts解析的，故babel-plugin-import是不能直接使用的，需要采用builtin:swc-loader的rspackExperiments來(lái)進(jìn)行對(duì)應(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)是通過(guò)auto-css-modules來(lái)進(jìn)行css-modules代碼的判斷；其原理為通過(guò)ast語(yǔ)法樹，判斷import引入樣式文件時(shí)，若有聲明對(duì)應(yīng)的變量，就將其打上一個(gè)query標(biāo)記。并在樣式文件處理時(shí)，通過(guò)resourceQuery來(lái)進(jìn)行匹配對(duì)應(yīng)的文件，并添加css-modules的編譯能力。詳情見：UmiJS AutoCssModules插件源代碼、UmiJS CSS編譯配置源代碼。

通過(guò)UmiJS項(xiàng)目以及結(jié)合一些資料，Babel的auto-css-modules能力有swc-plugin-auto-css-modules可以替代，配置的話，主要幾個(gè)關(guān)鍵點(diǎn)：

• 添加swc-plugin-auto-css-modules插件（實(shí)際上開源的插件并不能用，后文詳細(xì)說(shuō)明原因）。
• 添加builtins.css配置，指定cssModules編譯時(shí)的方式，主要有樣式名是否保持，輸出的樣式格式。
• 添加resourceQuery識(shí)別，并給對(duì)應(yīng)的內(nèi)容加type: 'css/module'；Rspack默認(rèn)會(huì)對(duì)type: 'css/module'的代碼當(dāng)做cssModules編譯，這個(gè)用法會(huì)比使用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]這種寫法就會(huì)報(bào)錯(cuò)
        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: [
          {
            // 通過(guò)resourceQuery來(lái)匹配?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í)際上上述的配置并不能直接跑起來(lái)，運(yùn)行時(shí)會(huì)提示構(gòu)建報(bào)錯(cuò)（RuntimeError: out of bounds memory accesSS），錯(cuò)誤如下圖：

圖片

結(jié)合github上的相關(guān)issue最終定位為swc_core版本不兼容的問(wèn)題導(dǎo)致。

原因詳解：

• Rspack使用的swc_core為0.88.x~0.89.x對(duì)應(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)致無(wú)法生成的wasm調(diào)用無(wú)法兼容。

問(wèn)題解決辦法：實(shí)際上只要通過(guò)將swc-plugin-auto-css-modules的swc_core版本修改為0.88.x~0.89.x這個(gè)范圍內(nèi)，再編譯出新的wasm文件即可解決；若有其他類似情況，也可以借鑒一下。

具體操作步驟：

• 將swc-plugin-auto-css-modules的swc_core修改版本后，在本地構(gòu)建生成一個(gè)wasm文件，并放到項(xiàng)目?jī)?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)目相對(duì)目錄下的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時(shí)，也能感受到有一定的性能開銷；同時(shí)在Rspack中，官方文檔中也有說(shuō)明當(dāng)devtool開啟并設(shè)置sourcemap時(shí)有性能開銷。官方文檔：

圖片

實(shí)際體驗(yàn)下來(lái)，source-map的模式損耗確實(shí)是大，大約會(huì)增加30%的耗時(shí)，而其他一些模式在構(gòu)建損耗上會(huì)有所優(yōu)化，具體可視使用情況來(lái)選擇建議在開發(fā)測(cè)試環(huán)境不使用，僅在線上等需要的環(huán)境開啟。相同應(yīng)用和機(jī)器環(huán)境，不同devtool的幾種測(cè)試表現(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的樣式，非但沒(méi)有作用反而讓構(gòu)建打包和應(yīng)用訪問(wèn)性能更差。

以下為英特爾i5芯片差異情況（M2等芯片在耗時(shí)上會(huì)縮小一些）：

在css-moduels中（比如：大多數(shù)頁(yè)面less、組件less）：每引入一次，大約增加6~7s左右構(gòu)建時(shí)間，css文件大約增加660kb。

在非css-moduels中（比如：global.less）：每引入一次，大約增加4~5s構(gòu)建時(shí)間，css文件大約增加530kb。

??????：建議平時(shí)項(xiàng)目中排查注意一下，可以將此類代碼進(jìn)行刪除，一個(gè)小小的習(xí)慣就可以直接提升不小的構(gòu)建和訪問(wèn)性能。

七、未來(lái)規(guī)劃

整個(gè)項(xiàng)目過(guò)程下來(lái)，收獲頗豐。一個(gè)是對(duì)前端構(gòu)建以及Rust方面有了更多的認(rèn)識(shí)，另外在接入過(guò)程中，也對(duì)當(dāng)前的應(yīng)用現(xiàn)狀和技術(shù)體系由了更深入的了解。但當(dāng)前項(xiàng)目主要服務(wù)于自身的業(yè)務(wù)的開發(fā)測(cè)試環(huán)境，使用范圍還相對(duì)比較窄，還存在一些轉(zhuǎn)換能力缺失的情況。未來(lái)將持續(xù)完善現(xiàn)有的構(gòu)建轉(zhuǎn)換能力，來(lái)拓展更多的業(yè)務(wù)應(yīng)用場(chǎng)景。

八、特別說(shuō)明

由于文章內(nèi)的相關(guān)內(nèi)容實(shí)踐已經(jīng)落地有了一段時(shí)間，文章內(nèi)的一些內(nèi)容可能已經(jīng)發(fā)生了變化，若存在出入煩請(qǐng)以相應(yīng)產(chǎn)品的官方介紹為準(zhǔn)。比如：Rspack的新版本已經(jīng)升級(jí)了swc_core到v0.91.x~v0.93.x兼容了swc-plugin-auto-css-modules的1.6.0版本，Turbopack計(jì)劃未來(lái)全面支持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