混合執行環境 程式語言
Maguyva 對 JavaScript 的支援：為混合執行環境儲存庫打造的 AI 搜尋
當儲存庫混雜了 CommonJS、ESM、工作腳本、測試與較舊的應用程式碼時，這特別有用。
AST 與符號支援 AST 解析 符號擷取 圖譜關係
副檔名
.cjs, .js, .mjs, .spec.js, 還有 2 個
開啟指南
為什麼 TypeScript 頁面很重要
TypeScript 正是許多團隊期待 AI 協助重構終於能讓人放心的語言。型別系統確實有幫助，但它並沒有解決真正的問題：共用套件、DTO、自動生成的 client、React 元件、測試與應用程式碼，全都在一個大型儲存庫中拉扯著同樣的名稱。
對 TypeScript 而言，標準要比「它理解語法」高得多。代理需要在編輯一個共用型別、hook 或 client 之前，一路追蹤合約，從定義到實作，再到影響範圍。
Maguyva 在 TypeScript 中實際擷取了什麼
Maguyva 會橫跨 .ts、.mts、.cts，以及測試與 story 檔案周邊常見的 TypeScript 檔案變體，擷取類別、方法、介面與型別別名。成員前綴會被正規化，但類別限定的識別碼會被保留下來——這在一個儲存庫同時存在未加限定的輔助函式名稱，以及最終片段相同的類別作用域中的方法時，特別有幫助。
JSX 會被視為真正的結構訊號，而不是零散的標記。在已建立索引的 TypeScript 檔案中，測試、story 與設定仍會與應用程式碼一同提供，協助代理在修改共用元件或服務前檢查使用範例與設定。
對 TypeScript 儲存庫有用的 MCP 工作流程
通常三種起始模式就已足夠：
- 當你已知介面、型別別名、hook 或 service 名稱時，使用
find_symbol。 - 在變更可能橫跨多個套件的共用型別或 client 之前，使用
dependency_search。 - 當你需要的是程式碼形狀、而不是關鍵字比對時——例如重複出現的元件或方法模式——使用
structural_search。
對於像「追蹤結帳送出流程」這類概念性問題，get_task_context 通常會是比原始搜尋更好的第一步。
這個頁面最適合的情境
這個頁面最適合 TypeScript 作為多個套件協調層的 Web 與平台 Monorepo。如果你的儲存庫仍包含大量較舊的 JS，可以參閱 JavaScript 指南。如果你真正想問的是「代理能不能同時掌握應用程式碼與基礎架構情境？」，可以將這個頁面與 Terraform 搭配閱讀。
最適合的情境
- > 在單一 TypeScript 儲存庫中運行 Next.js、Node 服務、共用套件與工具鏈的產品與平台團隊。
- > 介面、DTO、schema 與 React 元件彼此連動、卻分散在不同目錄中的儲存庫。
- > 在讓 AI 代理動手處理共用型別或套件邊界之前，努力為其提供安全情境的團隊。
代理工作流程
- > 追蹤一個型別、介面或元件，從其定義一路追到實際使用它的程式碼路徑。
- > 在變更一個共用輔助函式或 API 合約之前，先比較各套件間的實作方式。
- > 繪製出編輯某個共用型別、工具函式或服務模組時，可能造成的影響範圍。
引擎細節
- > Maguyva 的 TypeScript 支援會擷取類別、方法、介面與型別別名，而不是把所有東西都攤平成通用符號。
- > 成員前綴會被移除，但類別限定的識別碼會被保留，這有助於區分 `CheckoutService.create` 與未加限定的 `create`。
- > JSX 元素會被視為實例化。在已建立索引的 TypeScript 檔案中，測試、story 與設定仍會與應用程式碼一同提供作為上下文。
實用的 MCP 進入點
- find_symbol
當你知道要檢查的共用介面、型別別名、hook 或服務時，從這裡開始。
- dependency_search
在變更共用的 DTO 或用戶端之前使用，取得跨套件的真實影響範圍。
- structural_search
當你需要的是模式，而不是字串比對時，使用 AST 層級的搜尋，例如重複出現的元件或方法結構。