1. 為什么我會(huì)跟rea較上勁組件依賴失真的日常先交代一下背景。我之前在一個(gè)維護(hù)了三年的中后臺(tái)項(xiàng)目里天天跟幾百個(gè) React 組件打交道。那段時(shí)間最折磨人的不是寫新功能而是改老組件——你永遠(yuǎn)不知道一個(gè)看起來人畜無害的 props 改動(dòng)會(huì)在哪個(gè)犄角旮旯的頁面里炸出類型錯(cuò)誤。有一次我要給一個(gè)按鈕組件加個(gè)新參數(shù)全局搜了一遍引用肉眼數(shù)出十一個(gè)地方在用改完之后測試環(huán)境直接紅了四個(gè)頁面原因是有兩個(gè)組件通過一個(gè)我沒注意到的中間層間接引用了它。這種經(jīng)歷多了之后我開始琢磨一件事團(tuán)隊(duì)嘴上說的組件化開發(fā)實(shí)際上對(duì)組件之間關(guān)系的理解是高度私有的。每個(gè)人腦子里都有一張模糊的依賴圖但沒人能畫出來新來的同事更是只能靠猜。文檔寫過幾版很快就過期了IDE 自帶的結(jié)構(gòu)視圖只能看單文件跨文件關(guān)系全靠人肉。我那時(shí)候特別想要一個(gè)東西能自動(dòng)把整個(gè)項(xiàng)目的組件依賴關(guān)系摸清楚然后把結(jié)果變成一張看得懂的報(bào)表。這就是 rea 的起點(diǎn)。rea 不是那種幫你寫代碼的框架也不是約束代碼風(fēng)格的 lint 工具它是一個(gè)面向 React 項(xiàng)目的依賴關(guān)系分析器。它能掃描一個(gè)目錄把組件之間復(fù)雜的引用關(guān)系拉成一張結(jié)構(gòu)化的網(wǎng)告訴你誰依賴誰、誰在反復(fù)被引用、哪里有循環(huán)依賴、哪個(gè)組件已經(jīng)沒人用了但還在倉庫里躺著。對(duì)維護(hù)老項(xiàng)目的人來說它就是一次組件關(guān)系普查對(duì)剛接手代碼庫的人來說它就是一張不用維護(hù)、永遠(yuǎn)最新的架構(gòu)地圖。我自己定義 rea 的定位是它不是代碼規(guī)范工具而是關(guān)系普查工具。規(guī)范工具告訴你該怎么寫rea 告訴你現(xiàn)在到底是什么樣。先搞清楚現(xiàn)狀再談改進(jìn)這個(gè)順序不能反。1.1 一次改一處崩三處的實(shí)際案例具體說說那次讓我下決心的經(jīng)歷。項(xiàng)目里有一個(gè)UserAvatar組件最初只是在用戶列表里顯示頭像和名字后來被人擴(kuò)展了幾次增加了在線狀態(tài)、部門標(biāo)簽、跳轉(zhuǎn)鏈接等能力。我接手時(shí)顯示用戶信息這個(gè)需求已經(jīng)有三個(gè)組件在各自實(shí)現(xiàn)全都直接或間接引用了UserAvatar。我改了UserAvatar的 props 結(jié)構(gòu)把原來分散的幾個(gè)參數(shù)合并成一個(gè)user對(duì)象。結(jié)果列表頁直接引用它報(bào)錯(cuò)預(yù)期內(nèi)詳情頁的MemberCard引用了UserAvatar它自己又把 props 透傳出去報(bào)錯(cuò)也能理解最詭異的是ChatPanel它壓根沒寫過UserAvatar但它的子組件MessageItem里用了MemberCard于是錯(cuò)誤一路傳上來整個(gè)聊天面板崩潰。這個(gè)問題的本質(zhì)不是UserAvatar改得不好而是團(tuán)隊(duì)對(duì)誰在依賴誰這件事完全沒有共識(shí)。我當(dāng)時(shí)花了半小時(shí)翻引用、回看提交記錄、問之前的維護(hù)人才拼出這張圖。如果有工具能在改動(dòng)前五分鐘生成一份依賴清單后面這些返工根本不會(huì)發(fā)生。1.2 大多數(shù)人是怎么理清依賴關(guān)系的我觀察了一下不同團(tuán)隊(duì)的做法大致分三種第一種是硬記派。項(xiàng)目規(guī)模小的時(shí)候還好超過五十個(gè)組件之后就全靠個(gè)人記憶離職一個(gè)人就帶走一部分地圖。第二種是文檔派。ARTS 架構(gòu)圖、Notion 頁面畫得漂漂亮亮但代碼一變文檔就沒人更新三個(gè)月之后文檔描述的系統(tǒng)跟真實(shí)代碼已經(jīng)不是一個(gè)東西了。第三種是工具派。用 IDE 的 Find Usages、用 grep 搜 import 語句比前兩種靠譜但只適合查單個(gè)組件做不了全量分析更發(fā)現(xiàn)不了間接引用和循環(huán)依賴。這三種做法共同的問題在于它們都在處理人應(yīng)該怎么理解代碼而 rea 處理的是代碼之間的關(guān)系應(yīng)該怎么被計(jì)算。后者是確定性的是可以自動(dòng)化的而且是項(xiàng)目發(fā)展的過程中唯一不會(huì)撒謊的信息源——源碼本身。1.3 rea 的定位先普查再規(guī)劃我給自己定的原則很簡單先把現(xiàn)狀完整地、準(zhǔn)確地呈現(xiàn)出來讓團(tuán)隊(duì)在同一個(gè)事實(shí)基礎(chǔ)上討論問題。至于怎么重構(gòu)、怎么分層那是后面的事情。這就像接手一個(gè)老倉庫之前你先別急著清理貨架先做一次盤點(diǎn)哪些貨有人買哪些貨積壓了幾個(gè)月哪些貨放在兩個(gè)不同的貨架上。rea 做的就是這件事它把組件依賴這種抽象的、藏在代碼里的關(guān)系變成一份可以打印出來、可以在會(huì)議上指著討論的清單。2. rea 三個(gè)字母背后的架構(gòu)取向項(xiàng)目起名叫 rea不是隨手敲的。三個(gè)字母分別對(duì)應(yīng)我設(shè)計(jì)的三個(gè)階段Relate、Export、Analyze。這也決定了工具的整體架構(gòu)不是一個(gè)單點(diǎn)腳本而是三條清晰的處理流水線。2.1 Relate以依賴圖為中心的關(guān)系建模Relate 階段負(fù)責(zé)回答一個(gè)問題這個(gè)項(xiàng)目的組件之間到底有哪些關(guān)系在這個(gè)階段rea 不關(guān)心組件內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)不關(guān)心樣式怎么寫只關(guān)注一個(gè)東西引用關(guān)系。誰 import 了誰誰在 JSX 里渲染了誰誰通過 React.lazy 動(dòng)態(tài)加載了誰這些信息被統(tǒng)一收集起來形成一個(gè)以組件為節(jié)點(diǎn)、以引用為邊的有向圖。我選擇有向圖作為核心數(shù)據(jù)結(jié)構(gòu)是有原因的。第一有向圖天然能表達(dá)A 依賴 B但 B 不依賴 A這種非對(duì)稱關(guān)系這個(gè)在 UI 組件場景里非常常見——底層組件永遠(yuǎn)不知道誰在用自己。第二圖結(jié)構(gòu)方便做后續(xù)分析比如找環(huán)、算入度出度、做連通性判斷這些都是圖論里的經(jīng)典問題不需要發(fā)明新算法。這個(gè)階段最忌諱的是把出現(xiàn)過的字符串當(dāng)成真正的依賴。比如有的組件在注釋里寫了Button有的組件在字符串拼接里用了組件名這些都不能算數(shù)。rea 只認(rèn)兩類東西真實(shí)的 import 語句以及 JSX 里實(shí)際渲染的組件標(biāo)簽。寧可漏掉一些模糊的情況也不能把假依賴混進(jìn)圖里否則后面所有分析都是臟數(shù)據(jù)。2.2 Export從源碼到結(jié)構(gòu)化報(bào)表的流水線Relate 階段產(chǎn)出的是一張內(nèi)存里的圖但人沒法直接看內(nèi)存圖所以還需要一個(gè) Export 階段。這個(gè)階段做的事是把依賴圖轉(zhuǎn)換成一系列結(jié)構(gòu)化輸出。目前 rea 支持三種格式JSON給程序讀方便二次加工Markdown 表格給人讀方便貼進(jìn)文檔或者發(fā)到群里以及一個(gè)簡單的 HTML 報(bào)告用顏色和連線把依賴關(guān)系可視化出來適合在評(píng)審會(huì)上投屏講解。Export 階段有個(gè)容易被忽視的設(shè)計(jì)點(diǎn)輸出格式不能影響分析結(jié)果。也就是說不管你是要 JSON 還是 HTML底層那張依賴圖必須是同一張。我在設(shè)計(jì) rea 的時(shí)候把 Relate 和 Export 嚴(yán)格分成了兩層中間通過一個(gè)統(tǒng)一的內(nèi)部模型傳遞數(shù)據(jù)不能讓某個(gè)輸出格式反過來影響分析邏輯。2.3 Analyze把看得見的關(guān)系變成說得清的決策前兩個(gè)階段解決的是看到了什么Analyze 階段解決的是這意味著什么。同樣是一張依賴圖不同角色關(guān)心的點(diǎn)完全不同后端開發(fā)拿到這張圖關(guān)心的是循環(huán)依賴會(huì)不會(huì)導(dǎo)致初始化死循環(huán)前端 Leader 關(guān)心的是某個(gè)底層組件被三百個(gè)地方引用改動(dòng)它是不是高風(fēng)險(xiǎn)新人關(guān)心的是這個(gè)組件能不能刪刪了會(huì)不會(huì)有什么隱形依賴繃斷性能優(yōu)化的人關(guān)心的是有沒有組件在一個(gè)頁面里被重復(fù)渲染多次是不是因?yàn)槎鄠€(gè)入口都引到了同一個(gè)子組件。Analyze 階段把這些關(guān)心點(diǎn)轉(zhuǎn)化成具體的判定規(guī)則輸出帶有傾向性的結(jié)論。比如循環(huán)依賴警告高危公共組件提示孤兒組件提示。這些結(jié)論不一定都是錯(cuò)的但至少能讓討論有一個(gè)共同的出發(fā)點(diǎn)。3. 從 JSX 到依賴圖譜rea 的解析鏈路拆解知道整體架構(gòu)之后我想把解析鏈路拆開講一遍。理解這條鏈路你才能自己改 rea 去適配特殊項(xiàng)目或者在其他語言、其他框架里復(fù)現(xiàn)同樣的思路。3.1 第一層文件遍歷與入口發(fā)現(xiàn)rea 的起點(diǎn)不是某個(gè)具體文件而是整個(gè)目錄。你可以給它一個(gè)入口文件比如src/App.tsx它會(huì)順著這個(gè)入口往外擴(kuò)散也可以不指定入口直接掃描整個(gè)src目錄把所有.tsx、.ts、.jsx、.js文件都納入分析范圍。這一層有個(gè)重要參數(shù)叫--depth控制遞歸深度。默認(rèn)不限制但如果是第一次對(duì)一個(gè)老項(xiàng)目跑分析我建議先限制在四層以內(nèi)把主干關(guān)系看清楚再逐步加深。否則幾百個(gè)組件的圖展開之后信息量太大反而抓不住重點(diǎn)。文件遍歷階段會(huì)順帶做兩個(gè)過濾node_modules目錄直接跳過測試文件和.stories.tsx文件默認(rèn)跳過但可以通過參數(shù)手動(dòng)開啟。測試文件里經(jīng)常有 mock 數(shù)據(jù)導(dǎo)致的關(guān)系沖突故事文件依賴的引用方式也跟業(yè)務(wù)組件不一樣混在一起會(huì)污染分析結(jié)果。3.2 第二層AST 解析與導(dǎo)入聲明收集拿到文件列表之后rea 會(huì)對(duì)每個(gè)文件做詞法分析和語法分析。這里用的是成熟的 JS 解析器先把源碼解析成 AST抽象語法樹然后從中提取結(jié)構(gòu)化的語法事實(shí)。在這一步rea 核心收集的信息是兩類第一類是import聲明。不管是import A from ./A、import { B } from ./B還是import type { C } from ./C都會(huì)被抓出來。這里要特別注意區(qū)分type導(dǎo)入——它只影響類型檢查不影響運(yùn)行邏輯如果混進(jìn)依賴圖會(huì)制造大量虛假的運(yùn)行時(shí)依賴所以 rea 把 type-only 導(dǎo)入單獨(dú)標(biāo)記默認(rèn)不計(jì)入運(yùn)行時(shí)依賴圖。第二類是 JSX 標(biāo)簽。一個(gè)組件文件可能沒有顯式 import 某個(gè)組件但通過全局注冊(cè)或者window掛載的方式在 JSX 里使用了它。rea 會(huì)把 JSX 里出現(xiàn)的組件標(biāo)簽名跟當(dāng)前文件的 import 列表做交叉比對(duì)識(shí)別出用了但沒本地導(dǎo)入的組件這種往往是隱式依賴風(fēng)險(xiǎn)點(diǎn)。AST 這層看起來復(fù)雜其實(shí)邏輯可以用一句話概括把代碼從給人看的文本變成給機(jī)器看的樹然后在樹上做遍歷和標(biāo)記。下面這是 rea 內(nèi)部處理 import 語句的核心邏輯示意用 TypeScript 寫的import { parse } from babel/parser; import traverse from babel/traverse; export function extractImports(filePath: string, source: string) { const ast parse(source, { sourceType: module, plugins: [jsx, typescript, decorators-legacy], }); const imports: Array{ source: string; importedName: string; isTypeOnly: boolean; } []; traverse(ast, { ImportDeclaration(path) { const node path.node; node.specifiers.forEach((spec) { imports.push({ source: node.source.value, importedName: spec.type ImportDefaultSpecifier ? default : spec.local.name, isTypeOnly: node.importKind type, }); }); }, }); return imports; }實(shí)際的 rea 代碼比這個(gè)復(fù)雜一些因?yàn)檫€要處理 re-export、namespace import、動(dòng)態(tài) import 等情況但核心思路就是上面的代碼解析、遍歷、收集。3.3 第三層組件識(shí)別與依賴權(quán)重計(jì)算拿到所有的 import 關(guān)系之后會(huì)得到一個(gè)非常稠密的圖。一個(gè)工具函數(shù)可能被五十個(gè)組件引用了一個(gè) UI 組件可能引用了十幾個(gè)其他組件。如果直接把這個(gè)圖鋪開信息噪音很大。所以 rea 在第三層做了一件事給每條邊賦予權(quán)重給每個(gè)節(jié)點(diǎn)賦予角色。節(jié)點(diǎn)角色的判定規(guī)則是這樣的文件名首字母大寫且文件里有 JSX 返回值判定為組件文件名小寫且文件不在 UI 目錄下判定為工具模塊文件里沒有任何導(dǎo)出只包含副作用邏輯判定為副作用模塊一個(gè)文件同時(shí)導(dǎo)出組件和其他函數(shù)判定為混合模塊。邊權(quán)重的計(jì)算規(guī)則是直接引用記 1 分通過 re-export 間接引用記 0.5 分通過動(dòng)態(tài) importReact.lazy或import()調(diào)用引用記 0.3 分。簡單說越是直接的、靜態(tài)的、運(yùn)行時(shí)就確定的依賴權(quán)重越高越是一層套一層的間接引用權(quán)重越低。下面這張表是 rea 對(duì)節(jié)點(diǎn)角色和邊權(quán)重的默認(rèn)設(shè)定節(jié)點(diǎn)角色判定依據(jù)風(fēng)險(xiǎn)傾向組件首字母大寫、含 JSX作為依賴源影響下游使用者工具模塊小寫命名、純邏輯作為被依賴方支撐多個(gè)組件副作用模塊無導(dǎo)出、有副作用邏輯導(dǎo)入即執(zhí)行隱藏風(fēng)險(xiǎn)高混合模塊組件與函數(shù)同時(shí)導(dǎo)出依賴關(guān)系模糊建議拆分類型模塊僅導(dǎo)出類型不計(jì)入運(yùn)行時(shí)依賴3.4 第四層環(huán)形依賴與懸空引用的判定最后這一步是 rea 最有實(shí)用價(jià)值的部分在圖里找環(huán)、找懸空引用。環(huán)形依賴指的是 A 依賴 B、B 又依賴 A 的情況。在 React 項(xiàng)目里環(huán)形依賴不一定立刻讓程序崩潰但會(huì)讓模塊加載順序變得不確定容易出現(xiàn)某個(gè)組件渲染時(shí)拿到 undefined的詭異 bug而且這種 bug 非常難復(fù)現(xiàn)。rea 用深度優(yōu)先搜索遍歷有向圖一旦發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)出現(xiàn)在當(dāng)前遍歷路徑上就認(rèn)定存在環(huán)并輸出完整的環(huán)路鏈路。懸空引用則有兩種情況。一種是源碼里 import 了一個(gè)不存在的路徑這通常是重構(gòu)時(shí)漏改了另一種是 import 的模塊存在但里面沒有導(dǎo)出你要的那個(gè)名字這通常是導(dǎo)出的名字被改掉了。這兩種情況 rea 都會(huì)匯總成一個(gè)斷鏈清單方便你一次性修復(fù)。需要說明的是rea 的循環(huán)依賴檢測只是針對(duì)靜態(tài)分析的運(yùn)行時(shí)動(dòng)態(tài)創(chuàng)建依賴導(dǎo)致的環(huán)它檢測不到。但實(shí)際情況里靜態(tài)層面的循環(huán)依賴已經(jīng)覆蓋了絕大多數(shù)問題場景動(dòng)態(tài)依賴那部分占比很低。4. 在真實(shí)項(xiàng)目里跑一遍安裝、掃描、報(bào)表解讀說了這么多原理下面實(shí)際操作一遍。我用一個(gè)模擬的中后臺(tái)項(xiàng)目做演示項(xiàng)目結(jié)構(gòu)大概是這樣的src/ components/ common/ # 通用基礎(chǔ)組件比如 Button、Input、Modal business/ # 業(yè)務(wù)組件比如 UserCard、OrderTable pages/ Dashboard.tsx UserList.tsx OrderDetail.tsx utils/ format.ts request.ts App.tsx4.1 安裝與前置條件rea 是一個(gè)命令行工具全局安裝就能用。項(xiàng)目本身不要求 React 版本只要源碼是標(biāo)準(zhǔn)的 JS/TS 語法就行。如果項(xiàng)目用了比較新的 ECMAScript 語法或者實(shí)驗(yàn)性的裝飾器語法rea 會(huì)盡量用 AST 解析器的插件去兼容。npm i -g rea-cli安裝完成后先跑一下版本驗(yàn)證rea --version如果你更希望把它作為項(xiàng)目內(nèi)的開發(fā)依賴可以局部安裝然后用npx rea調(diào)用這樣團(tuán)隊(duì)里每個(gè)人能用的版本都能鎖定避免在我電腦上能跑的問題。4.2 第一次掃描會(huì)得到什么進(jìn)入項(xiàng)目根目錄跑第一條命令rea scan --entry src/App.tsx --out ./rea-report--entry指定入口文件--out指定輸出目錄。跑完之后會(huì)生成幾個(gè)文件rea-report/ report.json # 全量結(jié)構(gòu)化數(shù)據(jù) overview.md # 概覽報(bào)表 dependency-graph.html # 可視化關(guān)系圖 issues.md # 問題清單第一次掃描的結(jié)果通常會(huì)讓你吃一驚。以我自己的項(xiàng)目為例第一次跑出來這些數(shù)據(jù)全項(xiàng)目一共有 87 個(gè)組件、34 個(gè)工具模塊其中 29 個(gè)組件從來沒有任何地方引用它們也就是孤兒組件檢測到 3 組循環(huán)依賴其中一組跨了 6 個(gè)文件有一個(gè)底層組件被 74 個(gè)其他組件直接或間接引用?？吹?9 個(gè)組件沒人用的時(shí)候我是很震驚的。它們大多是為了某個(gè)半途而廢的功能寫的或者被替換之后忘了刪。如果不做普查這些代碼會(huì)一直躺在倉庫里成為新人閱讀代碼時(shí)的干擾噪音。4.3 看懂三張核心報(bào)表overview.md是一張組件依賴總表按引用數(shù)量排序所以進(jìn)入這個(gè)表格第一眼就能看到高危組件。表結(jié)構(gòu)大致是這樣組件名被引用次數(shù)被間接引用循環(huán)依賴風(fēng)險(xiǎn)等級(jí)Button74132無高危Modal4588無中危UserCard2341有高危DeprecatedBadge30無低危被引用次數(shù)高意味著改動(dòng)成本高風(fēng)險(xiǎn)等級(jí)是 rea 綜合了引用基數(shù)、間接引用量、環(huán)檢測結(jié)果算出來的。這個(gè)表不能直接決定你這個(gè)組件能不能改但能告訴你改之前要花多少精力做回歸測試。issues.md則是問題清單會(huì)列出所有檢測到的問題包括環(huán)路由、懸空引用、孤兒組件、副作用模塊的位置。這個(gè)清單最有價(jià)值的地方在于它給了你一個(gè)可以逐條消化的待辦列表而不是一個(gè)模糊的感覺項(xiàng)目有些問題。HTML 可視化圖適合拉到會(huì)議室里投屏。每個(gè)組件節(jié)點(diǎn)用圓形表示顏色深淺代表引用熱度箭頭代表依賴方向。人手一點(diǎn)開看哪里是重災(zāi)區(qū)一目了然。4.4 把 rea 接進(jìn) CI 的配置示例手動(dòng)跑一次只是清理問題真正要讓依賴關(guān)系長期可控得把它接進(jìn)持續(xù)集成流程。我推薦的做法是在代碼合并前加一步檢查依賴情況跟基線報(bào)告不一致就報(bào)警讓開發(fā)者自己在提測前就知道影響范圍。package.json里增加一條腳本{ scripts: { rea:check: rea scan --entry src/App.tsx --compare ./rea-report/baseline.json --check-cycle --check-orphan } }--compare參數(shù)會(huì)拿當(dāng)前掃描結(jié)果跟上次的基線做差異對(duì)比如果有新增的循環(huán)依賴或者新出現(xiàn)的高危組件命令會(huì)以非零碼退出CI 就會(huì)攔截這次合并。這里提個(gè)建議CI 里跑分析時(shí)盡量選一個(gè)穩(wěn)定的入口文件不要用src全量掃描作為判斷標(biāo)準(zhǔn)。因?yàn)槿繏呙鑼?duì)每次的改動(dòng)差異太敏感很容易因?yàn)橐恍o關(guān)緊要的改名導(dǎo)致整個(gè)流水線變紅時(shí)間久了大家就不看這個(gè)檢查了。入口聚焦到某幾條核心鏈路反而能形成有意義的約束。5. 實(shí)戰(zhàn)中繞不開的三個(gè)坑工具做出來是一回事拿到真實(shí)項(xiàng)目里跑是另一回事。rea 在反復(fù)打磨的過程中遇到了三個(gè)讓我印象很深的坑這里單獨(dú)拿出來講。5.1 動(dòng)態(tài) import 與 React.lazy 造成的盲區(qū)第一版 rea 只處理靜態(tài)的import語句很快就在一個(gè)項(xiàng)目上栽了跟頭。那個(gè)項(xiàng)目大量使用路由懶加載所有頁面組件都寫在React.lazy(() import(./pages/xxx))里。rea 跑完之后頁面組件全部出現(xiàn)在孤兒組件清單里因?yàn)殪o態(tài) import 抓不到這種動(dòng)態(tài)引用的關(guān)系。這個(gè)坑的本質(zhì)是靜態(tài)分析和動(dòng)態(tài)加載天然存在盲區(qū)。但這里的盲區(qū)不是一個(gè)無解的難題因?yàn)閯?dòng)態(tài) import 的路徑參數(shù)通常是一個(gè)字符串字面量還是可以從 AST 里提取的。我后來在 rea 里加了對(duì)import()調(diào)用表達(dá)式的解析能識(shí)別出React.lazy和loadable()這幾種常見的動(dòng)態(tài)加載封裝的參數(shù)把動(dòng)態(tài)引用也納入依賴圖。但有一種情況只能靠約定來補(bǔ)路徑變量拼接比如import(./locales/${lang})這種動(dòng)態(tài)性太強(qiáng)任何靜態(tài)分析工具都無能為力。遇到這種代碼只能用配置的方式在 rea 里手動(dòng)聲明這層關(guān)系或者干脆接受它不在依賴圖里。5.2 路徑別名與 barrel file 帶來的假依賴第二個(gè)坑是路徑別名?，F(xiàn)在主流 React 項(xiàng)目都會(huì)配路徑別名/components/Button這種寫法到處都是。第一版 rea 直接拿絕對(duì)路徑去做匹配結(jié)果/components/Button和../components/Button指向同一文件在依賴圖里卻被當(dāng)成了兩個(gè)不同的節(jié)點(diǎn)導(dǎo)致整個(gè)圖出現(xiàn)了大量重復(fù)節(jié)點(diǎn)引用次數(shù)統(tǒng)計(jì)嚴(yán)重失真。解決思路是對(duì)路徑做歸一化先讀取項(xiàng)目的tsconfig.json或者jsconfig.json提取paths字段的別名映射再把所有 import 的路徑根據(jù)映射關(guān)系解析成真實(shí)文件路徑最后基于真實(shí)文件路徑做去重。這里有一個(gè)優(yōu)先級(jí)問題也一并說一下如果項(xiàng)目里同時(shí)有tsconfig.json和webpack.config.js我建議優(yōu)先信tsconfig.json的映射因?yàn)樗?TypeScript 類型檢查實(shí)際在用的那份配置跟代碼能成功編譯的路徑保持一致。第三個(gè)坑是 barrel file也就是index.ts這種集中轉(zhuǎn)發(fā)的文件。一個(gè)目錄里的組件都通過index.tsre-export 出去其他組件再從index.ts導(dǎo)入。這在依賴圖里會(huì)形成一層很厚的中間節(jié)點(diǎn)分析結(jié)果里出現(xiàn)大量組件 A → index.ts → 組件 B的間接路徑。rea 的默認(rèn)策略是把 barrel file 當(dāng)作透明的轉(zhuǎn)發(fā)層穿透它直接連接真實(shí)的來源組件讓依賴圖更干凈。但如果你們團(tuán)隊(duì)有意把index.ts當(dāng)作對(duì)外 API 邊界不想穿透也可以關(guān)掉這個(gè)行為。我把這三個(gè)配置項(xiàng)整理成一個(gè)速查表問題參數(shù)作用需要掃描動(dòng)態(tài)導(dǎo)入--include-dynamic解析import()調(diào)用需要自動(dòng)讀取別名--resolve-alias-from tsconfig按 tsconfig 歸一化路徑需要穿透 index.ts--resolve-barrel穿過 barrel file 直達(dá)真實(shí)組件不想穿透 barrel--keep-barrel保留中間轉(zhuǎn)發(fā)層節(jié)點(diǎn)5.3 大項(xiàng)目掃描性能與緩存策略最后一個(gè)坑是性能。第一次在一個(gè)有幾百個(gè)組件的項(xiàng)目上跑時(shí)rea 全量掃描花了將近四十秒。單次跑還能接受但接進(jìn) CI 之后每次提交都等四十秒開發(fā)體驗(yàn)很差而且很容易導(dǎo)致流水線超時(shí)。性能瓶頸主要在兩處。一是重復(fù)解析同一個(gè)工具模塊被多個(gè)組件引用每次都在 import 解析時(shí)被重新讀文件、重新做 AST這對(duì)純函數(shù)模塊來說是純浪費(fèi)。二是級(jí)聯(lián)分析rea 需要沿著依賴關(guān)系逐層往外找模塊數(shù)量一大遞歸展開的路徑指數(shù)級(jí)增長。優(yōu)化方案做了兩個(gè)。第一個(gè)是文件級(jí)緩存基于文件內(nèi)容哈希做緩存只有內(nèi)容變了才重新解析。第二次掃描如果項(xiàng)目沒有改動(dòng)耗時(shí)直接從四十秒降到三秒以內(nèi)。第二個(gè)是定時(shí)清理緩存每次掃描時(shí)如果發(fā)現(xiàn)緩存目錄里的條目超過一定數(shù)量或者緩存文件太老會(huì)自動(dòng)重建。這個(gè)方案讓 rea 既快又不會(huì)積累垃圾數(shù)據(jù)。6. 目前正在嘗試的幾個(gè)迭代方向rea 現(xiàn)在已經(jīng)在團(tuán)隊(duì)內(nèi)部穩(wěn)定用了幾個(gè)月效果是實(shí)打?qū)嵉?。但工具這個(gè)東西用起來之后總能看到新的可能性這里列幾個(gè)我正在嘗試的方向。6.1 讓版本控制信息參與依賴決策當(dāng)前 rea 只分析源碼現(xiàn)狀不關(guān)心歷史。一個(gè)組件被引用了一百次和另一個(gè)組件也被引用了一百次對(duì) rea 來說風(fēng)險(xiǎn)等級(jí)一樣。但實(shí)際上這兩個(gè)組件的維護(hù)成本完全可能差很多前者三個(gè)月沒動(dòng)過很穩(wěn)定后者這周已經(jīng)被改了五回每次改都牽扯一堆人。我開始嘗試把版本控制系統(tǒng)信息接進(jìn)來比如給每個(gè)依賴關(guān)系打上最近更新時(shí)間和變更頻率兩個(gè)標(biāo)簽。標(biāo)簽不改變依賴圖結(jié)構(gòu)只是給風(fēng)險(xiǎn)等級(jí)計(jì)算增加一個(gè)維度一個(gè)高頻變更的組件如果又是高被引用的組件那它就是這個(gè)項(xiàng)目里最值得優(yōu)先重構(gòu)的對(duì)象。6.2 從分析工具變成約束工具分析工具只負(fù)責(zé)匯報(bào)約束工具還能在代碼提交前攔住問題。我的目標(biāo)是讓 rea check 能按團(tuán)隊(duì)自定義的規(guī)則執(zhí)行循環(huán)依賴新增攔截高危組件被新增引用超過 N 次攔截并提示拆分新增孤兒組件提示確認(rèn)而非直接攔截組件目錄深度超過約定層數(shù)提示檢查是否過度嵌套。規(guī)則全部寫在項(xiàng)目根目錄的.rea.config.json里不同項(xiàng)目可以配不同的閾值。這種紅線式的約束比讓人自學(xué)規(guī)范靠譜得多。6.3 給組件的健康打一個(gè)綜合分最后一個(gè)方向比較實(shí)驗(yàn)性把依賴圖指標(biāo)和可維護(hù)性指標(biāo)合在一起算一個(gè)組件健康分。參考維度包括被引用次數(shù)、是否存在循環(huán)依賴、組件文件行數(shù)、導(dǎo)出結(jié)構(gòu)是否單一、是否在測試文件和業(yè)務(wù)文件里被同時(shí)引用。健康分不追求工程學(xué)正確只是想讓團(tuán)隊(duì)在談代碼好壞時(shí)能有一個(gè)直觀的數(shù)字抓手。把這個(gè)數(shù)字展示在組件的開發(fā)文檔頁面里每周自動(dòng)刷新一次讓技術(shù)債變得可見。技術(shù)債不可怕可怕的是看不見。最后再分享兩個(gè)小技巧從項(xiàng)目立項(xiàng)到穩(wěn)定使用其實(shí)整個(gè)周期不到一個(gè)月但收益遠(yuǎn)超預(yù)期。最大的收獲不是那些報(bào)表本身而是團(tuán)隊(duì)開始用同一套語言討論組件邊界了——這個(gè)組件是重度的動(dòng)它要小心終于有了數(shù)據(jù)支撐而不是憑感覺。最后送兩個(gè)小技巧。第一個(gè)排查老項(xiàng)目問題時(shí)先跑rea scan --entry src/App.tsx它會(huì)產(chǎn)出一份當(dāng)下最新的依賴清單比你在代碼里一個(gè)文件一個(gè)文件地點(diǎn)要全面得多。第二個(gè)如果你的項(xiàng)目里 tsconfig 和 webpack 的別名配置不一致rea 默認(rèn)會(huì)讀取 tsconfig經(jīng)常對(duì)不上的建議把 webpack 的 resolve.alias 統(tǒng)一到 tsconfig 同源一勞永逸。依賴關(guān)系從來不會(huì)因?yàn)槟悴豢此筒淮嬖?。早一點(diǎn)把它拉出來擺到桌面上改代碼的時(shí)候會(huì)踏實(shí)很多。