用 AST 消除 Config-driven Framework 的雙重 Schema 維護

情境

我加入 Gorilla 時，公司原本就已經有一套 Config-driven No-code Framework。

使用者可以透過平台選擇 React Component、調整 Props 與版面，再由 Renderer 根據 Config 動態產生頁面。

但當時有一個維護問題：

Component 本身已經有 Props 定義，平台卻還需要另外維護一份 JSON Schema，才能知道編輯器應該提供哪些設定。

也就是每新增或修改一個 Component，工程師除了改程式碼之外，還必須同步修改對應的 Schema。

當 Component 數量持續增加，兩份定義只要有一邊忘記更新，平台編輯器看到的能力就可能與實際 Component 不一致。

我的判斷與做法

我認為這個問題不應該靠工程師「記得同步兩份檔案」解決。

Component 的 Props 本來就已經描述了它真正支援的能力，所以另一份 Schema 應該從程式碼推導，而不是再人工定義一次。

因此我使用 AST 與 ts-morph，在 Build 階段解析 React Component 的 Props 定義，自動萃取並產生平台需要的 JSON Schema。

原本：

Component Props → 人工維護 JSON Schema → Editor

改成：

Component Props → AST 解析 → 自動產生 JSON Schema → Editor

Framework 原本的 Config-driven 模型不需要被推翻，只是把其中最容易產生不同步的人工維護環節移除。

形成的結果

新增或修改 Component 時，工程師不需要再同步維護另一份 Schema 定義。

平台編輯器使用的結構可以直接跟著實際程式碼演進，也讓既有 No-code Framework 更容易持續擴充新的 Component 能力。

留下的思考

這件事後來成為我很常使用的一種判斷方式：

如果兩份資訊描述的是同一件事情，而且其中一份可以從另一份可靠地推導，就不應該要求人同時維護兩份。

真正容易失控的往往不是程式碼有多複雜，而是系統裡存在太多「理論上應該保持一致」的副本。