訊文檔是一款在線協(xié)作編輯工具,可用于多人實(shí)時(shí)編輯文檔、表格和幻燈片等。以下是使用騰訊文檔進(jìn)行在線編輯的基本步驟:
1、登錄:在瀏覽器中打開(kāi)騰訊文檔的網(wǎng)頁(yè)(搜索“騰訊文檔”就能找到地址),使用騰訊賬號(hào)登錄或者使用微信掃碼登錄。
2、創(chuàng)建文檔:登錄后,點(diǎn)擊左上角的“新建”按鈕,選擇創(chuàng)建的文檔類(lèi)型(文檔、表格或幻燈片)。
3、編輯文檔:在創(chuàng)建的文檔中,可以像使用常規(guī)編輯器一樣進(jìn)行文字輸入、格式設(shè)置、插入圖片和鏈接等操作。
4、評(píng)論和批注:在編輯過(guò)程中,可以通過(guò)選中文字、點(diǎn)擊右側(cè)出現(xiàn)的插入批注按鈕,在文檔中添加評(píng)論批注或者@他人,方便與其他人進(jìn)行交流和協(xié)作。
5、共享和協(xié)作:點(diǎn)擊右上角的“分享”按鈕,可以將文檔鏈接發(fā)送給其他人共享和協(xié)作。也可以設(shè)置權(quán)限,指定其他人可查看、編輯或評(píng)論文檔。
右上會(huì)出現(xiàn)正在查看的人頭像圖標(biāo)。多人編輯時(shí),可以看到其他人的光標(biāo)位置和實(shí)時(shí)編輯內(nèi)容。
6、版本控制:騰訊文檔支持文件版本控制功能,可以在編輯過(guò)程中保存文檔的不同版本,并在需要時(shí)進(jìn)行查看和恢復(fù)。
點(diǎn)擊右上角的“三橫杠”圖標(biāo)。點(diǎn)擊“版本歷史記錄”。
在版本歷史記錄頁(yè)面,即可查看文檔的“所有創(chuàng)建人、修改時(shí)間和修改內(nèi)容”。
7、導(dǎo)出和下載:完成編輯后,點(diǎn)擊右上角的“三橫杠”圖標(biāo),可以將文檔導(dǎo)出為Word、PDF、圖片、HTML等格式,直接下載到本地計(jì)算機(jī)。
以上是騰訊文檔在線編輯的基本使用方法,具體操作步驟可能會(huì)有一些微小的差異,以實(shí)際使用為準(zhǔn)。
本次操作演示使用的操作環(huán)境如下:
硬件型號(hào):ThinkPad T14
系統(tǒng)版本:Windows 10
APP版本:騰訊文檔在線版 3.0
者:glendonli,騰訊 PCG 前端開(kāi)發(fā)工程師
對(duì)于大型前端項(xiàng)目而言,構(gòu)建的穩(wěn)定性和易用性至關(guān)重要,騰訊文檔在迭代過(guò)程中,復(fù)雜的項(xiàng)目結(jié)構(gòu)和編譯帶來(lái)的問(wèn)題日益增多,極大的增加了新人上手與日常搬磚的開(kāi)銷(xiāo)。恰逢 Webpack5 上線,不如來(lái)一次徹底的魔改。
騰訊文檔最近基于剛剛發(fā)布的 Webpack5 進(jìn)行了一次編譯的大重構(gòu),作為一個(gè)多個(gè)倉(cāng)庫(kù)共同構(gòu)成的大型項(xiàng)目,任意品類(lèi)的代碼量都超過(guò)百萬(wàn)。對(duì)于騰訊文檔這樣一個(gè)快速迭代,高度依賴自動(dòng)化流水線,常年并行多個(gè)大型需求和無(wú)數(shù)小需求的項(xiàng)目來(lái)說(shuō),穩(wěn)定且快速的編譯對(duì)于開(kāi)發(fā)效率至關(guān)重要。這篇文章,就是筆者最近進(jìn)行重構(gòu),成功將日常開(kāi)發(fā)優(yōu)化到 1s 的過(guò)程中,遇到的一些大型項(xiàng)目特有的問(wèn)題和思考,希望能給大家在前端項(xiàng)目構(gòu)建的優(yōu)化中帶來(lái)一些參考和啟發(fā)。
隨著項(xiàng)目體系的逐漸擴(kuò)大,往往會(huì)遇到舊的編譯配置無(wú)法支持新特性,由于各種 config 文件自帶的閱讀 debuff,以及累累的技術(shù)債,大家總會(huì)趨于不去修改舊配置,而是試圖新增一些配置在外圍對(duì)編譯系統(tǒng)進(jìn)行修正。也是這樣類(lèi)似的原因,騰訊文檔過(guò)去的編譯編譯也并不優(yōu)雅:
多級(jí)的子倉(cāng)庫(kù)結(jié)構(gòu),復(fù)雜的編譯系統(tǒng)造成很高的理解和改動(dòng)成本,也帶來(lái)了較高的編譯耗時(shí),對(duì)于整個(gè)團(tuán)隊(duì)的開(kāi)發(fā)效率有著不小的影響。
為了解決編譯復(fù)雜和緩慢的問(wèn)題,至關(guān)重要的,就是禁止套娃:多層級(jí)混合的系統(tǒng)必須廢除,統(tǒng)一的編譯才是王道。在所有編譯系統(tǒng)中,Webpack 在大項(xiàng)目的打包上具備很強(qiáng)優(yōu)勢(shì),插件系統(tǒng)最為豐滿,并且 Webpack5 帶來(lái)了 Module Federation 新特性,因此筆者選擇了用 Webpack 來(lái)統(tǒng)合多個(gè)子倉(cāng)庫(kù)的編譯。
騰訊文檔使用了 lerna 來(lái)管理倉(cāng)庫(kù)中的子包,使用 lerna 的好處此處就不作展開(kāi)了。不過(guò) lerna 的通用用法也帶來(lái)了一定的問(wèn)題,lerna 將一個(gè)倉(cāng)庫(kù)變成了結(jié)構(gòu)上的多個(gè)倉(cāng)庫(kù),如果按照默認(rèn)的使用方式,每個(gè)倉(cāng)庫(kù)都會(huì)有自己的編譯配置,單個(gè)項(xiàng)目的編譯變成了多個(gè)項(xiàng)目的聯(lián)編聯(lián)調(diào),修改配置和增量?jī)?yōu)化都會(huì)變得比較困難。
雖然使用 lerna 的目的是使各個(gè)子包相對(duì)獨(dú)立,但是在整個(gè)項(xiàng)目的編譯調(diào)試中,往往需要的是所有包的集合,那么,筆者就可以忽略掉這個(gè)子包間的物理隔離,把子倉(cāng)庫(kù)作為子目錄來(lái)看待。不依賴 lerna,筆者需要解決的,是子包間的引用問(wèn)題:
/** package/layout/src/xxx.ts **/
import { Stream } from '@core/model';
// do something
事實(shí)上,筆者可以通過(guò) webpack 配置中 resolve 的 alias 屬性來(lái)達(dá)到相應(yīng)效果:
{
resolve: {
alias: {
'@core/model': 'word/package/model/src/',
}
}
}
在大型項(xiàng)目中,有時(shí)會(huì)存在一些特殊的靜態(tài)代碼文件,它們往往并不參與到打包系統(tǒng)中,而是由其他方式直接引入 html,或者合并到最終的結(jié)果中。
這樣的文件,一般分為如下幾類(lèi):
由于 polyfill 和外部 sdk 往往直接通過(guò)掛全局變量運(yùn)行的模式,項(xiàng)目中往往會(huì)通過(guò)直接寫(xiě)入 html script 標(biāo)簽的方式引用它們。不過(guò),隨著此類(lèi)文件的增多,直接利用標(biāo)簽引用,對(duì)于版本管理和編譯流程都不友好,它們對(duì)應(yīng)的一些初始化邏輯,也無(wú)法添加到打包流程中來(lái)。這種情況,筆者建議手工的創(chuàng)建一個(gè) js 入口文件,對(duì)以上文件進(jìn)行引用,并作為 webpack 的一個(gè)入口。如此,就能通過(guò)代碼的方式,將這些散裝文件管理起來(lái)了:
import 'jquery';
import 'raven.min.js';
import 'log.js';
// ...
但是,一些外部的 js 可能依賴于其他 sdk,比如 jQuery,但是打包系統(tǒng)并不知道它們之間的依賴關(guān)系,導(dǎo)致 jQuery 沒(méi)有及時(shí)暴露到全局中,該怎么辦呢?事實(shí)上,webpack 提供了很靈活的方案來(lái)處理這些問(wèn)題,比如,筆者可以通過(guò) expose-loader,將 jQuery 的暴露到全局,供第三方引用。在騰訊文檔中,還包含了一些對(duì)遠(yuǎn)程 cdn 的 sdk 組件,這些 sdk 也需要引用一些庫(kù),比如 jQuery 的。因此,筆者還通過(guò) splitChunks 的配置,將 jQuery 重新分離出來(lái),放在了較早的加載時(shí)機(jī),保證基于 cdn 加載的 sdk 亦能正常初始化。
通過(guò)代碼引用,一方面,可以很好地進(jìn)行依賴文件的版本管理;另一方面,由于對(duì)應(yīng)文件的編譯也加入了打包流程,所有對(duì)應(yīng)文件的改動(dòng)都可以被動(dòng)態(tài)監(jiān)視到,有利于后續(xù)進(jìn)行增量編譯。同時(shí),由于 webpack 的封裝特點(diǎn),每個(gè)庫(kù)都會(huì)被包含在一個(gè) webpack_require 的特殊函數(shù)之中,全局變量的暴露數(shù)量也變得較為可控。
Webpack 提供了一個(gè)非常靈活的 html-webpack-plugin 來(lái)進(jìn)行 html 生成,它支持模板和一眾的專(zhuān)屬插件,但是,仍然架不住項(xiàng)目有一些特殊的需求,通用的插件配置要么無(wú)法滿足這些需求,要么適配的結(jié)果就十分難懂。這也是騰訊文檔在最初使用了 gulp 來(lái)生成 html 的原因,在 gulp 配置中,有很多自定義流程來(lái)滿足騰訊文檔的發(fā)布要求。
既然,gulp 可以自定義流程來(lái)實(shí)現(xiàn) html 生成,那么,筆者也可以單獨(dú)寫(xiě)一個(gè) webpack 插件來(lái)實(shí)現(xiàn)定制的流程。
Webpack 本身是一個(gè)非常靈活的系統(tǒng),它是一個(gè)按照特定的流程執(zhí)行的框架,在每個(gè)流程的不同的階段提供了不同的鉤子,通過(guò)各種插件去實(shí)現(xiàn)這些鉤子的回調(diào),來(lái)完成代碼的打包,事實(shí)上,webpack 本身就是由無(wú)數(shù)原生插件組成的。在這整個(gè)流程中,筆者可以做各種不同的事情來(lái)定制它。
對(duì)于生成 html 的場(chǎng)景,通過(guò)增加一個(gè)插件,在 webpack 處理生成文件的階段,將生成的 js、css 等資源文件,以及 ejs 模板和特殊配置整合到一起,再添加到 webpack 的 assets 集合中,便可以完成一次自定義的 html 生成。
compilation.hooks.processAssets.tap({
name: 'TemplateHtmlEmitPlugin',
stage: Compilation.PROCESS_ASSETS_STAGE_ADDITIONAL,
}, () => {
// custom generation
compilation.emitAsset(
`${parsed.name}.html`,
new sources.RawSource(source, true),
);
compilation.fileDependencies.addAll(dependencies);
});
在以上代碼中,大家可以留意到最后一句:compilation.fileDependencies.addAll(dependencies),通過(guò)這一句,筆者可以將所有被自定義生成所依賴的文件加入的 webpack 的依賴系統(tǒng)中,那么當(dāng)這些文件發(fā)生變更的時(shí)候,webpack 能夠自動(dòng)再次觸發(fā)對(duì)應(yīng)的生成流程。
至此,各路編譯都已經(jīng)統(tǒng)一化,筆者可以用一個(gè) webpack 編譯整個(gè)項(xiàng)目了,watch 和 devServer 也可以一起 high 起來(lái)。不過(guò),既然編譯可以統(tǒng)一,何不讓所有操作都整合起來(lái)呢?
基于 node_modules 不應(yīng)該手工操作的假設(shè),筆者可以創(chuàng)建 package.json 中依賴的快照,每次根據(jù) package 的變化來(lái)判斷是否需要重新安裝,避免開(kāi)發(fā)同學(xué)同步代碼后的手動(dòng)判斷,跳過(guò)不必要的步驟。
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)試是基于特殊的測(cè)試環(huán)境,通過(guò) whislte 進(jìn)行代理,這樣的步驟也可以自動(dòng)化,那么,對(duì)于開(kāi)發(fā)來(lái)說(shuō),一切就很輕松了,一條命令,輕松搬磚~
不過(guò),作為是一個(gè)復(fù)雜的系統(tǒng),第一次使用,總需要初始化的吧,如果編譯系統(tǒng)的依賴尚未安裝,沒(méi)有雞,怎么生蛋呢?
其實(shí)不然,筆者不妨在整套編譯系統(tǒng)的外層套個(gè)娃,做前端開(kāi)發(fā),node 總會(huì)先安裝的吧?那么,在執(zhí)行正在的編譯命令之前,筆者執(zhí)行一個(gè)只依賴于 node 的腳本,這個(gè)腳本會(huì)嘗試執(zhí)行主要命令,如果主命令直接 crash,說(shuō)明安裝環(huán)境尚未準(zhǔn)備完畢,那么這個(gè)時(shí)候,對(duì)編譯系統(tǒng)進(jìn)行初始化就 ok 了。如此,就真的可以做到一鍵開(kāi)發(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)過(guò)程中,筆者將原本的編譯配置改為了由 ts 調(diào)用 webpack 的 nodeApi 來(lái)執(zhí)行編譯。代碼化的編譯系統(tǒng)有諸多好處:
在涉及 typescript 編譯的項(xiàng)目中,基本的提速操作,就是異步的類(lèi)型檢查,ts-loader 的 tranpsileOnly 參數(shù)和 fork-ts-checker 的組合拳百試不厭。不過(guò),對(duì)于復(fù)雜的大型項(xiàng)目來(lái)說(shuō),這一套組合拳的啟用過(guò)程未必是一帆風(fēng)順,不妨隨著筆者一起看看,在騰訊文檔中,啟用快速編譯的坎坷之路。
在啟用 transpileOnly 參數(shù)后,編譯速度立即有了質(zhì)的提升,但是,結(jié)果并不樂(lè)觀。編譯后,頁(yè)面還沒(méi)打開(kāi),就 crash 了。根據(jù)報(bào)錯(cuò)查下去,發(fā)現(xiàn)一個(gè)從依賴庫(kù)導(dǎo)入的對(duì)象變成了 undefined,從而引起程序崩潰。這個(gè)變?yōu)?undefined 的對(duì)象,是一個(gè) enum,定義如下:
export const enumScope{
VAL1= 0,
VAL2= 1,
}
為什么當(dāng)筆者啟用了 transpileOnly 后它就為空了呢?這和它的特殊屬性有關(guān),它不是一個(gè)普通的 enum,它是一個(gè) const enum。眾所周知,枚舉是 ts 的語(yǔ)法糖,每一個(gè)枚舉,對(duì)應(yīng)了 js 中的一個(gè)對(duì)象,所以,一個(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;
也就是說(shuō),const enum 就和宏是等效的,在翻譯成 js 之后,它就不存在了。可是,為何在關(guān)閉 transpileOnly 時(shí),編譯結(jié)果可以正常運(yùn)行呢?其實(shí),仔細(xì)翻看外部庫(kù)的聲明文件.d.ts,就會(huì)發(fā)現(xiàn),在這個(gè).d.ts 文件中,Scope 被原封不動(dòng)地保留了下來(lái)。
// .d.ts
export const enumScope{
VAL1= 0,
VAL2= 1,
}
在正常的編譯流程下,tsc 會(huì)檢查.d.ts 文件,并且已經(jīng)預(yù)知了這一個(gè)定義,因此,它能夠正確的執(zhí)行宏轉(zhuǎn)換,而對(duì)于 transpileOnly 開(kāi)啟的情況下,所有的類(lèi)型被忽略,由于原本的庫(kù)模塊中已經(jīng)不存在 Scope 了,所以編譯結(jié)果無(wú)法正常執(zhí)行(PS:tsc 官方已經(jīng)表態(tài) transpile 模式下的編譯不解析.d.ts 是標(biāo)準(zhǔn) feature,丟失了 const enum 不屬于 bug,所以等待官方支持是無(wú)果的)。既然得知了緣由,就可以修復(fù)了。四種方案:
方案一,遵循官方指導(dǎo),對(duì)于不導(dǎo)出 const enum,只對(duì)內(nèi)部使用的枚舉 const 化,也就是說(shuō),需要修改依賴庫(kù)。當(dāng)然,騰訊文檔本次 crash 所有依賴庫(kù)確實(shí)屬于自有的 sdk,但是如果是外部的庫(kù)引起了該問(wèn)題呢?所以該方案并不保險(xiǎn)。
方案二,完美版,手動(dòng)解析.d.ts 文件,尋找所有 const enum 并提取定義。但是,transpileOnly 獲取的編譯加速真是得益于忽略.d.ts 文件,如果筆者再去為了一個(gè) enum 手工解析.d.ts,而.d.ts 文件可能存在復(fù)雜的引用鏈路,是極其耗時(shí)的。
方案三,字符串替換,既然 const enum 是宏,那么筆者可以手工通過(guò) string-replace-loader 達(dá)到類(lèi)似效果。不過(guò),字符串替換方式依舊過(guò)于暴力,如果使用了類(lèi)似于 Scope['VAL1']的用法,可能就猝不及防的失效了。
方案四,也是筆者最終所采取的方案,既然定義消失了,重新定義就好,通過(guò) Webpack 的 DefinePlugin,筆者可以重新定義丟失的對(duì)象,保證編譯的正常解析。
new DefinePlugin({
Scope: {VAL1: 0,VAL2: 1 },
})
很不幸,僅僅是解決了編譯對(duì)象丟失的問(wèn)題,代碼依舊無(wú)法運(yùn)行。程序在初始化的時(shí)候,依舊迷之失敗了,經(jīng)過(guò)一番調(diào)試,發(fā)現(xiàn),初始化流程有一些微妙的不同。很明顯,transpileOnly 開(kāi)啟的情況下,編譯的結(jié)果發(fā)生了變化。 要解決這個(gè)問(wèn)題,就需要對(duì) transpileOnly 模式的實(shí)現(xiàn)一探究竟了。transpileOnly 底層是基于 tsc 的 transpileModule 功能來(lái)實(shí)現(xiàn)的,transpileModule 的作用,是將每一個(gè)文件當(dāng)做獨(dú)立的個(gè)體進(jìn)行解析,每一個(gè) import 都會(huì)被當(dāng)做一個(gè)整體模塊來(lái)看待,編譯器不會(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();
如上是常見(jiàn)的代碼寫(xiě)法,我們往往會(huì)通過(guò)一個(gè) index.ts 導(dǎo)出 base 中的模塊,這樣,在其他模塊中,筆者就不需要引用到文件了。在正常模式下,編輯器解析這段代碼,會(huì)附帶信息,告知 webpack,A 是由 a.ts 導(dǎo)出的,因此,webpack 在打包時(shí),可以根據(jù)具體場(chǎng)景將 A、B 打包到不同的文件中。但是,在 transpileModule 模式下,webpack 所知道的,只有 base 模塊導(dǎo)出了 A,但是它并不知道 A 具體是由哪個(gè)文件導(dǎo)出的,因此,此時(shí)的 webpack 一定會(huì)將 A、B 打包到一個(gè)文件中,作為一整個(gè)模塊,提供給 App。對(duì)于騰訊文檔,這個(gè)情況發(fā)生了如下變化(模塊按照 1、2、3、4、5 的順序進(jìn)行加載,模塊的視覺(jué)大小表示體積大小):
可以看到,在 transpileOnly 開(kāi)啟的情況下,大量的文件被打包到了模塊 1 中,被提前加載了。不過(guò),一般情況下,模塊被打包到什么位置,并不應(yīng)該影響代碼的表現(xiàn),不是么?畢竟,關(guān)閉 code splitting,代碼是可以不拆包的。對(duì)于一般的情況而言,這樣理解并沒(méi)有錯(cuò)。但是,對(duì)于使用了 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)致了騰訊文檔無(wú)法正常啟動(dòng)呢?這,就要從騰訊文檔全面引入依賴注入技術(shù)開(kāi)始說(shuō)起。
在騰訊文檔中,每一個(gè)功能都是一個(gè) feature,這個(gè) feature 并不會(huì)手動(dòng)初始化,而是通過(guò)一個(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 的初始化帶來(lái)了某個(gè)副作用。然后,模塊 2 加載了,workbench 再次進(jìn)行一輪實(shí)力創(chuàng)建和初始化,此時(shí) FeatureC 的初始化依賴了 FeatureA 的副作用,但是第一輪初始化已經(jīng)結(jié)束,因此 C 順利實(shí)例化了。
當(dāng) transpileOnly 被開(kāi)啟式,一切變了樣,由于無(wú)法區(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)出的解析問(wèn)題,是否就迎刃而解了?不過(guò),這么多的代碼,改成這樣的引用,不但難看,反人類(lèi),工作量也很大。因此,讓筆者設(shè)計(jì)一個(gè) plugin/loader 組合在編譯時(shí)來(lái)解決問(wèn)題吧。在編譯的初始階段,筆者通過(guò)一個(gè) plugin,對(duì)項(xiàng)目文件進(jìn)行解析,將其中的 export 提取出來(lái),找到每一個(gè) export 和文件的對(duì)應(yīng)關(guān)系,并儲(chǔ)存起來(lái)(此處,可能大家會(huì)擔(dān)心 IO 讀寫(xiě)對(duì)性能的影響,考慮到現(xiàn)在開(kāi)發(fā)人均都是高速 SSD,這點(diǎn) IO 吞吐真的不算什么,實(shí)測(cè)這個(gè) export 解析<1s),然后在編譯過(guò)程中,筆者再通過(guò)一個(gè)自定義的 loader 將對(duì)應(yīng)的 import 語(yǔ)句進(jìn)行替換,這樣,就可以實(shí)現(xiàn)在不影響正常寫(xiě)代碼的情況下,保持 transpileOnly 解析的有效性了。
經(jīng)過(guò)一番折騰,終于,成功地將騰訊文檔在高速編譯模式下運(yùn)行了起來(lái),達(dá)到了預(yù)定的編譯速度。
Webpack5 畢竟屬于一次非兼容的大升級(jí),在騰訊文檔編譯系統(tǒng)重構(gòu)的過(guò)程中,也遇到諸多問(wèn)題。
如果你也是 splitChunks 的重度用戶,在升級(jí) webpack5 的過(guò)程中,你可能會(huì)遇到如下警告:
這個(gè)警告的說(shuō)明并不是十分明確,用大白話來(lái)說(shuō),出現(xiàn)了這個(gè)提示,說(shuō)明你的 chunkGroups 配置中,出現(xiàn)了 module 同時(shí)屬于 A、B 兩組(此處 A、B 是兩個(gè) Entrypoint 或者兩個(gè)異步模塊),但是你明確指定了將模塊屬于 A 的情況。為何此時(shí) Webpack5 會(huì)報(bào)出警告呢?因?yàn)閺耐ǔG闆r來(lái)說(shuō),module 分屬于兩個(gè) Entrypoint 或者異步模塊,module 應(yīng)該被提取為公共模塊的,如果 module 被歸屬于 A,那么 B 模塊如果單獨(dú)加載,就無(wú)法成功了。
不過(guò),一般來(lái)說(shuō),出現(xiàn)這樣的指定,如果不是配置錯(cuò)誤,那就是 A、B 之間已經(jīng)有明確的加載順序。但是這個(gè)加載順序,Webpack 并不知道。對(duì)于 entrypoint,webpack5 中,允許通過(guò) dependOn 屬性,指定 entry 之間的依賴關(guān)系。但是對(duì)于異步模塊,則沒(méi)有這么遍歷的設(shè)置。當(dāng)然,筆者也可以通過(guò)自定義插件,在 optimize 之前,對(duì)已有的模塊依賴關(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)相繼適配,大家只要將插件更新到最新版本即可。不過(guò),也有一些插件因?yàn)橹T多緣由,一些插件并沒(méi)有及時(shí)更新。(PS:目前,沒(méi)有匹配的插件大多已經(jīng)比較小眾了。)總之,這個(gè)問(wèn)題是比較無(wú)解的,不過(guò)可以適當(dāng)?shù)却瑧?yīng)該在近期,大部分插件都會(huì)適配 webpack5,事實(shí)上 webpack5 也是用了不少改名大法,部分接口進(jìn)行轉(zhuǎn)移,調(diào)用方式發(fā)生了改變,倒也沒(méi)有全部翻天覆地的變化,所以,實(shí)在等不及的小插件不妨試試自己 fork 修改一下。
通常,對(duì)于一個(gè)大型項(xiàng)目來(lái)說(shuō),筆者會(huì)抽取很多公共的組件來(lái)提高項(xiàng)目間的模塊共享,但是,這些模塊之間,難免會(huì)有一些共同依賴,比如 React、ReactDOM,JQuery 之類(lèi)的基礎(chǔ)庫(kù)。這樣,就容易造成一個(gè)問(wèn)題,公共組件抽取后,項(xiàng)目體積膨脹了。隨著公共組件的增多,項(xiàng)目體積的膨脹變得十分可怕。在傳統(tǒng)打包模型上,筆者摸索出了一套簡(jiǎn)單有效的方法,對(duì)于公共組件,筆者使用 external,將這些公共部分摳出來(lái),變成一個(gè)殘疾的組件。
但是,隨著組件的增多,共享組件的 Host 增多,這樣的方式帶來(lái)了一些問(wèn)題:
這個(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)過(guò)程中,可以通過(guò) webpack 的動(dòng)態(tài)加載運(yùn)行時(shí),只加載其中需要的部分,對(duì)于已經(jīng)存在的部分,則不作二次加載。(下圖中,由于 host 中已經(jīng)包含了 jQuery、react 和 dui,Webpack 的運(yùn)行時(shí)將只加載 Remote1 中的 Component1 和 Remote2 中的 Component2。)
也就是說(shuō),公共組件作為一個(gè) Remote,它包含了完整的運(yùn)行時(shí),Host 無(wú)需知道需要準(zhǔn)備什么樣的運(yùn)行時(shí)才可以運(yùn)行 Remote,但是 Webpack 的加載器保證了共享的代碼不作加載。如此一來(lái),就避免了傳統(tǒng) external 打包模式下的諸多問(wèn)題。事實(shí)上,一個(gè)組件可以同時(shí)是 Host 和 Remote,也就是說(shuō),一個(gè)程序既可以作為主程運(yùn)行,也可以作為一個(gè)在線的 sdk 倉(cāng)庫(kù)。關(guān)于 Module Federation 的實(shí)現(xiàn)原理,此處不再贅述,大家感興趣可以參考探索 webpack5 新特性 Module federation 在騰訊文檔的應(yīng)用中的解析,也可以多多參考module-federation-examples這個(gè)倉(cāng)庫(kù)中的實(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";
ReactDOM.render(<App />, 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è)倉(cāng)庫(kù)的聯(lián)動(dòng),它的推進(jìn)必然是相對(duì)漫長(zhǎng)的過(guò)程。那么筆者是否有必要將現(xiàn)有的項(xiàng)目直接改造為 index-bootstrap 結(jié)構(gòu)呢?事實(shí)上,筆者依然可以利用 Webpack 的插件機(jī)制,動(dòng)態(tài)實(shí)現(xiàn)這一個(gè)異步化過(guò)程:
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');
再通過(guò) webpack-virtual-modules 這個(gè)插件,在相同目錄生成一個(gè)虛擬文件,將原本的入口進(jìn)行替換,就完成了 module-federation 的結(jié)構(gòu)轉(zhuǎn)換。這樣,配合一些其他的相應(yīng)配置,筆者就可以通過(guò)一個(gè)簡(jiǎn)單參數(shù)開(kāi)啟和關(guān)閉 module-federation,把項(xiàng)目變成一個(gè) Webpack5 ready 的結(jié)構(gòu),當(dāng)相關(guān)項(xiàng)目陸續(xù)適配成功,便可以一起歡樂(lè)的上線了。
對(duì)編譯的大重構(gòu)是筆者蓄謀已久的事情,猶記得加入團(tuán)隊(duì)之時(shí),第一次接觸到編譯鏈路如此復(fù)雜的項(xiàng)目,深感自己的項(xiàng)目經(jīng)歷太淺,接觸的編譯和打包都如此簡(jiǎn)單,如今親自操刀才知道,這中間除了許多技術(shù)難題,大項(xiàng)目必有的祖?zhèn)髋渲靡彩亲璧K項(xiàng)目進(jìn)步的一大阻力。
Webpack 5 的 Beta 周期很長(zhǎng),所以在 Webpack5 發(fā)布之后,兼容問(wèn)題還真不如預(yù)想的那么多,不過(guò) Webpack5 的文檔有些坑,如果不是使用 NodeApi 的時(shí)候,有類(lèi)型聲明,筆者絕對(duì)無(wú)法發(fā)現(xiàn)官方不少文檔的給的參數(shù)還是 webpack4 的舊數(shù)據(jù),對(duì)不上號(hào)。于是不得不埋著頭調(diào)試源代碼,尋找正確的配置方式,不過(guò)也因此收獲良多。并且 Webpack5 還在持續(xù)迭代中,還存在一些 bug,比如 Module Federation 中使用了不恰當(dāng)?shù)呐渲茫赡軙?huì)導(dǎo)致奇怪的編譯結(jié)果,并且不會(huì)報(bào)錯(cuò)。所以,遇到問(wèn)題大家要大膽地提 issue。本次重構(gòu)的經(jīng)驗(yàn)就暫時(shí)說(shuō)到這兒,如有不當(dāng)之處,歡迎斧正。
*請(qǐng)認(rèn)真填寫(xiě)需求信息,我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。