對于大型前端項(xiàng)目而言，構(gòu)建的穩(wěn)定性和易用性至關(guān)重要，騰訊文檔在迭代過程中，復(fù)雜的項(xiàng)目結(jié)構(gòu)和編譯帶來的問題日益增多，極大的增加了新人上手與日常搬磚的開銷。恰逢 Webpack5 上線，不如來一次徹底的魔改。
騰訊文檔最近基于剛剛發(fā)布的 Webpack5 進(jìn)行了一次編譯的大重構(gòu)，作為一個(gè)多個(gè)倉庫共同構(gòu)成的大型項(xiàng)目，任意品類的代碼量都超過百萬。對于騰訊文檔這樣一個(gè)快速迭代，高度依賴自動(dòng)化流水線，常年并行多個(gè)大型需求和無數(shù)小需求的項(xiàng)目來說，穩(wěn)定且快速的編譯對于開發(fā)效率至關(guān)重要。這篇文章，就是筆者最近進(jìn)行重構(gòu)，成功將日常開發(fā)優(yōu)化到 1s 的過程中，遇到的一些大型項(xiàng)目特有的問題和思考，希望能給大家在前端項(xiàng)目構(gòu)建的優(yōu)化中帶來一些參考和啟發(fā)。
隨著項(xiàng)目體系的逐漸擴(kuò)大，往往會(huì)遇到舊的編譯配置無法支持新特性，由于各種 config 文件自帶的閱讀 debuff，以及累累的技術(shù)債，大家總會(huì)趨于不去修改舊配置，而是試圖新增一些配置在外圍對編譯系統(tǒng)進(jìn)行修正。也是這樣類似的原因，騰訊文檔過去的編譯編譯也并不優(yōu)雅：
多級的子倉庫結(jié)構(gòu)，復(fù)雜的編譯系統(tǒng)造成很高的理解和改動(dòng)成本，也帶來了較高的編譯耗時(shí)，對于整個(gè)團(tuán)隊(duì)的開發(fā)效率有著不小的影響。
為了解決編譯復(fù)雜和緩慢的問題，至關(guān)重要的，就是禁止套娃：多層級混合的系統(tǒng)必須廢除，統(tǒng)一的編譯才是王道。在所有編譯系統(tǒng)中，Webpack 在大項(xiàng)目的打包上具備很強(qiáng)優(yōu)勢，插件系統(tǒng)最為豐滿，并且 Webpack5 帶來了 Module Federation 新特性，因此筆者選擇了用 Webpack 來統(tǒng)合多個(gè)子倉庫的編譯。
騰訊文檔使用了 lerna 來管理倉庫中的子包，使用 lerna 的好處此處就不作展開了。不過 lerna 的通用用法也帶來了一定的問題，lerna 將一個(gè)倉庫變成了結(jié)構(gòu)上的多個(gè)倉庫，如果按照默認(rèn)的使用方式，每個(gè)倉庫都會(huì)有自己的編譯配置，單個(gè)項(xiàng)目的編譯變成了多個(gè)項(xiàng)目的聯(lián)編聯(lián)調(diào)，修改配置和增量優(yōu)化都會(huì)變得比較困難。
雖然使用 lerna 的目的是使各個(gè)子包相對獨(dú)立，但是在整個(gè)項(xiàng)目的編譯調(diào)試中，往往需要的是所有包的集合，那么，筆者就可以忽略掉這個(gè)子包間的物理隔離，把子倉庫作為子目錄來看待。不依賴 lerna，筆者需要解決的，是子包間的引用問題：
/** package/layout/src/xxx.ts **/
import { Stream } from '@core/model';
// do something
事實(shí)上，筆者可以通過 webpack 配置中 resolve 的 alias 屬性來達(dá)到相應(yīng)效果：
{
resolve: {
alias: {
'@core/model': 'word/package/model/src/',
}
}
}
在大型項(xiàng)目中，有時(shí)會(huì)存在一些特殊的靜態(tài)代碼文件，它們往往并不參與到打包系統(tǒng)中，而是由其他方式直接引入 html，或者合并到最終的結(jié)果中。
這樣的文件，一般分為如下幾類：
加載時(shí)機(jī)較早的外部 sdk 文件，本身以 minify 文件提供外部文件依賴的其他框架文件，比如 jquery一些 polyfill一些特殊的必須早期運(yùn)行的獨(dú)立邏輯，比如初始化 sdk 等
由于 polyfill 和外部 sdk 往往直接通過掛全局變量運(yùn)行的模式，項(xiàng)目中往往會(huì)通過直接寫入 html script 標(biāo)簽的方式引用它們。不過，隨著此類文件的增多，直接利用標(biāo)簽引用，對于版本管理和編譯流程都不友好，它們對應(yīng)的一些初始化邏輯，也無法添加到打包流程中來。這種情況，筆者建議手工的創(chuàng)建一個(gè) js 入口文件，對以上文件進(jìn)行引用，并作為 webpack 的一個(gè)入口。如此，就能通過代碼的方式，將這些散裝文件管理起來了：
import 'jquery';
import 'raven.min.js';
import 'log.js';
// ...
但是，一些外部的 js 可能依賴于其他 sdk，比如 jQuery，但是打包系統(tǒng)并不知道它們之間的依賴關(guān)系，導(dǎo)致 jQuery 沒有及時(shí)暴露到全局中，該怎么辦呢？事實(shí)上，webpack 提供了很靈活的方案來處理這些問題，比如，筆者可以通過 expose-loader，將 jQuery 的暴露到全局，供第三方引用。在騰訊文檔中，還包含了一些對遠(yuǎn)程 cdn 的 sdk 組件，這些 sdk 也需要引用一些庫，比如 jQuery 的。因此，筆者還通過 splitChunks 的配置，將 jQuery 重新分離出來，放在了較早的加載時(shí)機(jī)，保證基于 cdn 加載的 sdk 亦能正常初始化。
通過代碼引用，一方面，可以很好地進(jìn)行依賴文件的版本管理；另一方面，由于對應(yīng)文件的編譯也加入了打包流程，所有對應(yīng)文件的改動(dòng)都可以被動(dòng)態(tài)監(jiān)視到，有利于后續(xù)進(jìn)行增量編譯。同時(shí)，由于 webpack 的封裝特點(diǎn)，每個(gè)庫都會(huì)被包含在一個(gè) webpack_require 的特殊函數(shù)之中，全局變量的暴露數(shù)量也變得較為可控。
Webpack 提供了一個(gè)非常靈活的 html-webpack-plugin 來進(jìn)行 html 生成，它支持模板和一眾的專屬插件，但是，仍然架不住項(xiàng)目有一些特殊的需求，通用的插件配置要么無法滿足這些需求，要么適配的結(jié)果就十分難懂。這也是騰訊文檔在最初使用了 gulp 來生成 html 的原因，在 gulp 配置中，有很多自定義流程來滿足騰訊文檔的發(fā)布要求。
既然，gulp 可以自定義流程來實(shí)現(xiàn) html 生成，那么，筆者也可以單獨(dú)寫一個(gè) webpack 插件來實(shí)現(xiàn)定制的流程。
Webpack 本身是一個(gè)非常靈活的系統(tǒng)，它是一個(gè)按照特定的流程執(zhí)行的框架，在每個(gè)流程的不同的階段提供了不同的鉤子，通過各種插件去實(shí)現(xiàn)這些鉤子的回調(diào)，來完成代碼的打包，事實(shí)上，webpack 本身就是由無數(shù)原生插件組成的。在這整個(gè)流程中，筆者可以做各種不同的事情來定制它。
對于生成 html 的場景，通過增加一個(gè)插件，在 webpack 處理生成文件的階段，將生成的 js、css 等資源文件，以及 ejs 模板和特殊配置整合到一起，再添加到 webpack 的 assets 集合中，便可以完成一次自定義的 html 生成。
compilation.hookscessAssets.tap({
name: 'TemplateHtmlEmitPlugin',
stage: CompilationCESS_ASSETS_STAGE_ADDITIONAL,
}, ()=> {
// custom generation
compilation.emitAsset(
`${parsed.name}.html`,
new sources.RawSource(source, true),
);
compilation.fileDependencies.addAll(dependencies);
});
在以上代碼中，大家可以留意到最后一句：
compilation.fileDependencies.addAll(dependencies)，通過這一句，筆者可以將所有被自定義生成所依賴的文件加入的 webpack 的依賴系統(tǒng)中，那么當(dāng)這些文件發(fā)生變更的時(shí)候，webpack 能夠自動(dòng)再次觸發(fā)對應(yīng)的生成流程。
至此，各路編譯都已經(jīng)統(tǒng)一化，筆者可以用一個(gè) webpack 編譯整個(gè)項(xiàng)目了，watch 和 devServer 也可以一起 high 起來。不過，既然編譯可以統(tǒng)一，何不讓所有操作都整合起來呢？
基于 node_modules 不應(yīng)該手工操作的假設(shè)，筆者可以創(chuàng)建 package.json 中依賴的快照，每次根據(jù) package 的變化來判斷是否需要重新安裝，避免開發(fā)同學(xué)同步代碼后的手動(dòng)判斷，跳過不必要的步驟。
public async install(force=false) {
const startTime=performance.now();
const lastSnapshot=this.readSnapshot();
const snapshot=this.createSnapshot();
const runs=this.repoInfos.map((repo)=> {
if (
this.isRepoInstallMissing(repo.root)
|| (!repo.installed
&& (force || !isEqual(snapshot[repo.root], lastSnapshot[repo.root])))
) {
// create and return install cmd
}
return undefined;
}).filter(script=> !!script);
const { info }=console;
if (runs.length > 0) {
try {
// 執(zhí)行安裝并保存快照
await Promise.all(runs.map(run=> this.exec(run!.cmd, run!.cwd, run!.name)));
this.saveSnapshot(snapshot);
} catch (e) {
this.removeSnapshot();
throw e;
}
} else {
info(chalk.green('Skip install'));
}
info(chalk.bgGreen.black(`Install cost: ${TimeUtil.formatTime(performance.now() - startTime)}`));
}
同樣的，騰訊文檔的本地調(diào)試是基于特殊的測試環(huán)境，通過 whislte 進(jìn)行代理，這樣的步驟也可以自動(dòng)化，那么，對于開發(fā)來說，一切就很輕松了，一條命令，輕松搬磚~
不過，作為是一個(gè)復(fù)雜的系統(tǒng)，第一次使用，總需要初始化的吧，如果編譯系統(tǒng)的依賴尚未安裝，沒有雞，怎么生蛋呢？
其實(shí)不然，筆者不妨在整套編譯系統(tǒng)的外層套個(gè)娃，做前端開發(fā)，node 總會(huì)先安裝的吧？那么，在執(zhí)行正在的編譯命令之前，筆者執(zhí)行一個(gè)只依賴于 node 的腳本，這個(gè)腳本會(huì)嘗試執(zhí)行主要命令，如果主命令直接 crash，說明安裝環(huán)境尚未準(zhǔn)備完畢，那么這個(gè)時(shí)候，對編譯系統(tǒng)進(jìn)行初始化就 ok 了。如此，就真的可以做到一鍵開發(fā)了。
const cmd='啟動(dòng)編譯的命令';
const main=extraArg=> childProcess.execSync(`${cmd} ${extraArg}`, { stdio: 'inherit', cwd: __dirname });
try {
main('');
} catch (e) {
// 初始化
main('after-initialize');
}
在這一次的重構(gòu)過程中，筆者將原本的編譯配置改為了由 ts 調(diào)用 webpack 的 nodeApi 來執(zhí)行編譯。代碼化的編譯系統(tǒng)有諸多好處：
使用 api 調(diào)用，可以享受 IDE 帶來的代碼提示，再也不會(huì)因?yàn)椴恍⌒脑谂渲梦募锩娲蛄艘粋€(gè) typo 而調(diào)試一整天。使用代碼 api，能夠更好的實(shí)現(xiàn)編譯的結(jié)構(gòu)，特別是有多重輸出的時(shí)候，比起簡單的 config 文件組合，更好管理。使用代碼化的編譯系統(tǒng)，還有一個(gè)特別的作用，編譯系統(tǒng)也可以寫測試了！啥？編譯系統(tǒng)要寫測試？事實(shí)上，在騰訊文檔歷次的發(fā)布中，經(jīng)歷過數(shù)次莫名的 bug，在上線前的測試中，整個(gè)程序的表現(xiàn)突然就不正常了。相關(guān)代碼，并沒有任何改動(dòng)，大家地毯式的排查了很久，才發(fā)現(xiàn)編譯的結(jié)果和以前有微小的不同。事實(shí)上，在網(wǎng)上可查系統(tǒng)測試環(huán)境生成的前五個(gè)小時(shí)，一個(gè)編譯所依賴的插件默默地更新了一個(gè)小版本，而筆者在 package.json 中對該插件使用的是默認(rèn)的^xx.xx，流水線 install 到了最新的版本，導(dǎo)致了 crash。當(dāng)時(shí)筆者得出了一個(gè)結(jié)論，編譯相關(guān)的庫需要鎖定版本。但是，鎖定版本并不能真正的解決問題，編譯所使用的組件，總有升級的一天，如果保證這個(gè)升級不會(huì)引起問題呢？這就是自動(dòng)化測試的范疇了。事實(shí)上，如果大家看看 Webpack 的代碼，會(huì)發(fā)現(xiàn)他們也做了很多測試用例來編譯的一致性，但是，webpack 的插件五花八門，并不是每一個(gè)作者在質(zhì)量保障上都有足夠的投入，因此，用自動(dòng)化測試保證編譯系統(tǒng)的穩(wěn)定性，也是一個(gè)可以深入研究的課題。
在涉及 typescript 編譯的項(xiàng)目中，基本的提速操作，就是異步的類型檢查，ts-loader 的 tranpsileOnly 參數(shù)和 fork-ts-checker 的組合拳百試不厭。不過，對于復(fù)雜的大型項(xiàng)目來說，這一套組合拳的啟用過程未必是一帆風(fēng)順，不妨隨著筆者一起看看，在騰訊文檔中，啟用快速編譯的坎坷之路。
在啟用 transpileOnly 參數(shù)后，編譯速度立即有了質(zhì)的提升，但是，結(jié)果并不樂觀。編譯后，頁面還沒打開，就 crash 了。根據(jù)報(bào)錯(cuò)查下去，發(fā)現(xiàn)一個(gè)從依賴庫導(dǎo)入的對象變成了 undefined，從而引起程序崩潰。這個(gè)變?yōu)?undefined 的對象，是一個(gè) enum，定義如下：
export const enumScope{
VAL1=0,
VAL2=1,
}
為什么當(dāng)筆者啟用了 transpileOnly 后它就為空了呢？這和它的特殊屬性有關(guān)，它不是一個(gè)普通的 enum，它是一個(gè) const enum。眾所周知，枚舉是 ts 的語法糖，每一個(gè)枚舉，對應(yīng)了 js 中的一個(gè)對象，所以，一個(gè)普通的枚舉，轉(zhuǎn)化為 js 之后，會(huì)變成這樣：
// ts
export enum Scope {
VAL1=0,
VAL2=1,
}
const a=Scope.VAL1;
// js
constScope={
VAL1: 0,
VAL2: 1,
0: 'VAL1',
1: 'VAL2',
};
const a=Scope.EDITOR;
如果筆者給 Scope 加上一個(gè) const 關(guān)鍵字呢？它會(huì)變成這樣：
// ts
export const enumScope{
VAL1=0,
VAL2=1,
}
const a=Scope.VAL1;
// js
const a=0；
也就是說，const enum 就和宏是等效的，在翻譯成 js 之后，它就不存在了?？墒?，為何在關(guān)閉 transpileOnly 時(shí)，編譯結(jié)果可以正常運(yùn)行呢？其實(shí)，仔細(xì)翻看外部庫的聲明文件.d.ts，就會(huì)發(fā)現(xiàn)，在這個(gè).d.ts 文件中，Scope 被原封不動(dòng)地保留了下來。
// .d.ts
export const enumScope{
VAL1=0,
VAL2=1,
}
在正常的編譯流程下，tsc 會(huì)檢查.d.ts 文件，并且已經(jīng)預(yù)知了這一個(gè)定義，因此，它能夠正確的執(zhí)行宏轉(zhuǎn)換，而對于 transpileOnly 開啟的情況下，所有的類型被忽略，由于原本的庫模塊中已經(jīng)不存在 Scope 了，所以編譯結(jié)果無法正常執(zhí)行（PS：tsc 官方已經(jīng)表態(tài) transpile 模式下的編譯不解析.d.ts 是標(biāo)準(zhǔn) feature，丟失了 const enum 不屬于 bug，所以等待官方支持是無果的）。既然得知了緣由，就可以修復(fù)了。四種方案：
方案一，遵循官方指導(dǎo)，對于不導(dǎo)出 const enum，只對內(nèi)部使用的枚舉 const 化，也就是說，需要修改依賴庫。當(dāng)然，騰訊文檔本次 crash 所有依賴庫確實(shí)屬于自有的 sdk，但是如果是外部的庫引起了該問題呢？所以該方案并不保險(xiǎn)。
方案二，完美版，手動(dòng)解析.d.ts 文件，尋找所有 const enum 并提取定義。但是，transpileOnly 獲取的編譯加速真是得益于忽略.d.ts 文件，如果筆者再去為了一個(gè) enum 手工解析.d.ts，而.d.ts 文件可能存在復(fù)雜的引用鏈路，是極其耗時(shí)的。
方案三，字符串替換，既然 const enum 是宏，那么筆者可以手工通過 string-replace-loader 達(dá)到類似效果。不過，字符串替換方式依舊過于暴力，如果使用了類似于 Scope['VAL1']的用法，可能就猝不及防的失效了。
方案四，也是筆者最終所采取的方案，既然定義消失了，重新定義就好，通過 Webpack 的 DefinePlugin，筆者可以重新定義丟失的對象，保證編譯的正常解析。
new DefinePlugin({
Scope: {VAL1: 0,VAL2: 1 },
})
很不幸，僅僅是解決了編譯對象丟失的問題，代碼依舊無法運(yùn)行。程序在初始化的時(shí)候，依舊迷之失敗了，經(jīng)過一番調(diào)試，發(fā)現(xiàn)，初始化流程有一些微妙的不同。很明顯，transpileOnly 開啟的情況下，編譯的結(jié)果發(fā)生了變化。 要解決這個(gè)問題，就需要對 transpileOnly 模式的實(shí)現(xiàn)一探究竟了。transpileOnly 底層是基于 tsc 的 transpileModule 功能來實(shí)現(xiàn)的，transpileModule 的作用，是將每一個(gè)文件當(dāng)做獨(dú)立的個(gè)體進(jìn)行解析，每一個(gè) import 都會(huì)被當(dāng)做一個(gè)整體模塊來看待，編譯器不會(huì)再解析模塊導(dǎo)出與文件的具體關(guān)系，舉個(gè)例子：
// src/base/a.ts
export class A {}
// src/base/b.ts
export class B {}
// src/base/index.ts
export * from './a';
export * from './b'
// src/app.ts
import { A } from './base';
const a=new A();
如上是常見的代碼寫法，我們往往會(huì)通過一個(gè) index.ts 導(dǎo)出 base 中的模塊，這樣，在其他模塊中，筆者就不需要引用到文件了。在正常模式下，編輯器解析這段代碼，會(huì)附帶信息，告知 webpack，A 是由 a.ts 導(dǎo)出的，因此，webpack 在打包時(shí)，可以根據(jù)具體場景將 A、B 打包到不同的文件中。但是，在 transpileModule 模式下，webpack 所知道的，只有 base 模塊導(dǎo)出了 A，但是它并不知道 A 具體是由哪個(gè)文件導(dǎo)出的，因此，此時(shí)的 webpack 一定會(huì)將 A、B 打包到一個(gè)文件中，作為一整個(gè)模塊，提供給 App。對于騰訊文檔，這個(gè)情況發(fā)生了如下變化（模塊按照 1、2、3、4、5 的順序進(jìn)行加載，模塊的視覺大小表示體積大小）：
可以看到，在 transpileOnly 開啟的情況下，大量的文件被打包到了模塊 1 中，被提前加載了。不過，一般情況下，模塊被打包到什么位置，并不應(yīng)該影響代碼的表現(xiàn)，不是么？畢竟，關(guān)閉 code splitting，代碼是可以不拆包的。對于一般的情況而言，這樣理解并沒有錯(cuò)。但是，對于使用了 decorator 的項(xiàng)目而言，就不適用了。在代碼普遍會(huì)轉(zhuǎn)為 es5 的時(shí)代，decorator 會(huì)被轉(zhuǎn)換為一個(gè)__decorator 函數(shù)，這個(gè)函數(shù)，是代碼加載時(shí)的一個(gè)自執(zhí)行函數(shù)。如果代碼打包的順序發(fā)生了變化，那么自執(zhí)行函數(shù)的執(zhí)行順序也就可能發(fā)生了變化。那么，這又如何導(dǎo)致了騰訊文檔無法正常啟動(dòng)呢？這，就要從騰訊文檔全面引入依賴注入技術(shù)開始說起。
在騰訊文檔中，每一個(gè)功能都是一個(gè) feature，這個(gè) feature 并不會(huì)手動(dòng)初始化，而是通過一個(gè)特殊裝飾器，注入到騰訊文檔的 DI 框架中，然后，由注入框架進(jìn)行統(tǒng)一的實(shí)例創(chuàng)建。舉個(gè)例子，在正常的變一下，由三個(gè) Feature A、B、C，A、B 被編譯在模塊 1 中，C 被編譯到模塊 2 中。在模塊 1 加載時(shí)，workbench 會(huì)進(jìn)行一輪實(shí)例創(chuàng)建和初始化，此時(shí)，F(xiàn)eatureA 的初始化帶來了某個(gè)副作用。然后，模塊 2 加載了，workbench 再次進(jìn)行一輪實(shí)力創(chuàng)建和初始化，此時(shí) FeatureC 的初始化依賴了 FeatureA 的副作用，但是第一輪初始化已經(jīng)結(jié)束，因此 C 順利實(shí)例化了。
當(dāng) transpileOnly 被開啟式，一切變了樣，由于無法區(qū)分導(dǎo)出，F(xiàn)eature A、B、C 被打包到同一個(gè)模塊了?？上攵?，在 Feature C 初始化時(shí)，由于副作用尚未發(fā)生，C 的初始化就失敗了。
既然 transpileOnly 與依賴注入先天不兼容，那筆者就需要想辦法修復(fù)它。如果，筆者將 app 中的引用進(jìn)行替換：
// src/app.ts
import { A } from './base/a';
const a=new A();
模塊導(dǎo)出的解析問題，是否就迎刃而解了？不過，這么多的代碼，改成這樣的引用，不但難看，反人類，工作量也很大。因此，讓筆者設(shè)計(jì)一個(gè) plugin/loader 組合在編譯時(shí)來解決問題吧。在編譯的初始階段，筆者通過一個(gè) plugin，對項(xiàng)目文件進(jìn)行解析，將其中的 export 提取出來，找到每一個(gè) export 和文件的對應(yīng)關(guān)系，并儲存起來（此處，可能大家會(huì)擔(dān)心 IO 讀寫對性能的影響，考慮到現(xiàn)在開發(fā)人均都是高速 SSD，這點(diǎn) IO 吞吐真的不算什么，實(shí)測這個(gè) export 解析<1s），然后在編譯過程中，筆者再通過一個(gè)自定義的 loader 將對應(yīng)的 import 語句進(jìn)行替換，這樣，就可以實(shí)現(xiàn)在不影響正常寫代碼的情況下，保持 transpileOnly 解析的有效性了。
經(jīng)過一番折騰，終于，成功地將騰訊文檔在高速編譯模式下運(yùn)行了起來，達(dá)到了預(yù)定的編譯速度。
Webpack5 畢竟屬于一次非兼容的大升級，在騰訊文檔編譯系統(tǒng)重構(gòu)的過程中，也遇到諸多問題。
如果你也是 splitChunks 的重度用戶，在升級 webpack5 的過程中，你可能會(huì)遇到如下警告：
這個(gè)警告的說明并不是十分明確，用大白話來說，出現(xiàn)了這個(gè)提示，說明你的 chunkGroups 配置中，出現(xiàn)了 module 同時(shí)屬于 A、B 兩組（此處 A、B 是兩個(gè) Entrypoint 或者兩個(gè)異步模塊），但是你明確指定了將模塊屬于 A 的情況。為何此時(shí) Webpack5 會(huì)報(bào)出警告呢？因?yàn)閺耐ǔＧ闆r來說，module 分屬于兩個(gè) Entrypoint 或者異步模塊，module 應(yīng)該被提取為公共模塊的，如果 module 被歸屬于 A，那么 B 模塊如果單獨(dú)加載，就無法成功了。
不過，一般來說，出現(xiàn)這樣的指定，如果不是配置錯(cuò)誤，那就是 A、B 之間已經(jīng)有明確的加載順序。但是這個(gè)加載順序，Webpack 并不知道。對于 entrypoint，webpack5 中，允許通過 dependOn 屬性，指定 entry 之間的依賴關(guān)系。但是對于異步模塊，則沒有這么遍歷的設(shè)置。當(dāng)然，筆者也可以通過自定義插件，在 optimize 之前，對已有的模塊依賴關(guān)系以及修改，保證 webpack 能夠知曉額外的信息：
compiler.hooks.thisCompilation.tap('DependOnPlugin', (compilation)=> {
compilation.hooks.optimize.tap('DependOnPlugin', ()=> {
forEach(this.dependencies, (parentNames, childName)=> {
const child=compilation.namedChunkGroups.get(childName);
if (child) {
parentNames.forEach((parentName)=> {
const parent=compilation.namedChunkGroups.get(parentName);
if (parent && !child.hasParent(parent)) {
parent.addChild(child);
child.addParent(parent);
}
});
}
});
});
});
Webpack5 發(fā)布后，各大主流 plugin 都已經(jīng)相繼適配，大家只要將插件更新到最新版本即可。不過，也有一些插件因?yàn)橹T多緣由，一些插件并沒有及時(shí)更新。（PS：目前，沒有匹配的插件大多已經(jīng)比較小眾了。）總之，這個(gè)問題是比較無解的，不過可以適當(dāng)?shù)却瑧?yīng)該在近期，大部分插件都會(huì)適配 webpack5，事實(shí)上 webpack5 也是用了不少改名大法，部分接口進(jìn)行轉(zhuǎn)移，調(diào)用方式發(fā)生了改變，倒也沒有全部翻天覆地的變化，所以，實(shí)在等不及的小插件不妨試試自己 fork 修改一下。
通常，對于一個(gè)大型項(xiàng)目來說，筆者會(huì)抽取很多公共的組件來提高項(xiàng)目間的模塊共享，但是，這些模塊之間，難免會(huì)有一些共同依賴，比如 React、ReactDOM，JQuery 之類的基礎(chǔ)庫。這樣，就容易造成一個(gè)問題，公共組件抽取后，項(xiàng)目體積膨脹了。隨著公共組件的增多，項(xiàng)目體積的膨脹變得十分可怕。在傳統(tǒng)打包模型上，筆者摸索出了一套簡單有效的方法，對于公共組件，筆者使用 external，將這些公共部分摳出來，變成一個(gè)殘疾的組件。
但是，隨著組件的增多，共享組件的 Host 增多，這樣的方式帶來了一些問題：
Component 需要為 Host 專門打包，它不是一個(gè)可以獨(dú)立運(yùn)行的組件，每一個(gè)運(yùn)行該 Component 的 Host 必須攜帶完整的運(yùn)行時(shí)，否則 Component 就需要為不同的 Host 打出不同的殘疾包。Component 與 Component 之間如果存在較大的共享模塊，無法通過 external 解決。
這個(gè)時(shí)候，Module Federation 出現(xiàn)了，它是 Webpack 從靜態(tài)打包到完整運(yùn)行時(shí)的一個(gè)轉(zhuǎn)變，Module Federation 中，提出了 Host 和 Remote 的概念。Remote 中的內(nèi)容可以被 Host 消費(fèi)，而在這個(gè)消費(fèi)過程中，可以通過 webpack 的動(dòng)態(tài)加載運(yùn)行時(shí)，只加載其中需要的部分，對于已經(jīng)存在的部分，則不作二次加載。（下圖中，由于 host 中已經(jīng)包含了 jQuery、react 和 dui，Webpack 的運(yùn)行時(shí)將只加載 Remote1 中的 Component1 和 Remote2 中的 Component2。）
也就是說，公共組件作為一個(gè) Remote，它包含了完整的運(yùn)行時(shí)，Host 無需知道需要準(zhǔn)備什么樣的運(yùn)行時(shí)才可以運(yùn)行 Remote，但是 Webpack 的加載器保證了共享的代碼不作加載。如此一來，就避免了傳統(tǒng) external 打包模式下的諸多問題。事實(shí)上，一個(gè)組件可以同時(shí)是 Host 和 Remote，也就是說，一個(gè)程序既可以作為主程運(yùn)行，也可以作為一個(gè)在線的 sdk 倉庫。關(guān)于 Module Federation 的實(shí)現(xiàn)原理，此處不再贅述，大家感興趣可以參考探索 webpack5 新特性 Module federation 在騰訊文檔的應(yīng)用中的解析，也可以多多參考
module-federation-examples這個(gè)倉庫中的實(shí)例。
Webpack5 的 Module Federation 是依賴于其動(dòng)態(tài)加載機(jī)制的，因此，在它的演示實(shí)例中，你都可以看到這樣的結(jié)構(gòu)：
// bootstrap.js
import App from "./App";
import React from "react";
import ReactDOM from "react-dom";
ReactDOMder(, document.getElementById("root"));
// index.js
import('./bootstrap.js');
而 Webpack 的入口配置，都設(shè)置在了 index.js 上，這里，是因?yàn)樗械囊蕾嚩夹枰獎(jiǎng)討B(tài)判定加載，如果不把入口變成一個(gè)異步的 chunk，那如何去保障依賴能夠按順序加載內(nèi)？畢竟實(shí)現(xiàn) Moudle Federation 的核心是 基于 webpack_require 的動(dòng)態(tài)加載系統(tǒng)。由于 Module Federation 需要多個(gè)倉庫的聯(lián)動(dòng)，它的推進(jìn)必然是相對漫長的過程。那么筆者是否有必要將現(xiàn)有的項(xiàng)目直接改造為 index-bootstrap 結(jié)構(gòu)呢？事實(shí)上，筆者依然可以利用 Webpack 的插件機(jī)制，動(dòng)態(tài)實(shí)現(xiàn)這一個(gè)異步化過程：
private bootstrapEntry(entrypoint: string) {
const parsed=path.parse(entrypoint);
const bootstrapPath=path.join(parsed.dir, `${parsed.name}_bootstrap${parsed.ext}`);
this.virtualModules[bootstrapPath]=`import('./${parsed.name}${parsed.ext}')`;
return bootstrapPath;
}
在上述的 bootstrapEntry 方法中，筆者基于原本的 entrypoint 文件，創(chuàng)建一個(gè)虛擬文件，這個(gè)文件的內(nèi)容就是：
import('./entrypoint.ts');
再通過 webpack-virtual-modules 這個(gè)插件，在相同目錄生成一個(gè)虛擬文件，將原本的入口進(jìn)行替換，就完成了 module-federation 的結(jié)構(gòu)轉(zhuǎn)換。這樣，配合一些其他的相應(yīng)配置，筆者就可以通過一個(gè)簡單參數(shù)開啟和關(guān)閉 module-federation，把項(xiàng)目變成一個(gè) Webpack5 ready 的結(jié)構(gòu)，當(dāng)相關(guān)項(xiàng)目陸續(xù)適配成功，便可以一起歡樂的上線了。
對編譯的大重構(gòu)是筆者蓄謀已久的事情，猶記得加入團(tuán)隊(duì)之時(shí)，第一次接觸到編譯鏈路如此復(fù)雜的項(xiàng)目，深感自己的項(xiàng)目經(jīng)歷太淺，接觸的編譯和打包都如此簡單，如今親自操刀才知道，這中間除了許多技術(shù)難題，大項(xiàng)目必有的祖?zhèn)髋渲靡彩亲璧K項(xiàng)目進(jìn)步的一大阻力。
Webpack 5 的 Beta 周期很長，所以在 Webpack5 發(fā)布之后，兼容問題還真不如預(yù)想的那么多，不過 Webpack5 的文檔有些坑，如果不是使用 NodeApi 的時(shí)候，有類型聲明，筆者絕對無法發(fā)現(xiàn)官方不少文檔的給的參數(shù)還是 webpack4 的舊數(shù)據(jù)，對不上號。于是不得不埋著頭調(diào)試源代碼，尋找正確的配置方式，不過也因此收獲良多。并且 Webpack5 還在持續(xù)迭代中，還存在一些 bug，比如 Module Federation 中使用了不恰當(dāng)?shù)呐渲?，可能?huì)導(dǎo)致奇怪的編譯結(jié)果，并且不會(huì)報(bào)錯(cuò)。所以，遇到問題大家要大膽地提 issue。本次重構(gòu)的經(jīng)驗(yàn)就暫時(shí)說到這兒，如有不當(dāng)之處，歡迎斧正。
聯(lián)系客服
