混合运行时 编程语言
Maguyva 对 JavaScript 的支持：面向混合运行时代码仓库的 AI 搜索
适合那些混合了 CommonJS、ESM、任务脚本、测试和较旧应用代码的代码仓库。
AST 和符号支持 AST 解析 符号提取 图谱关系
扩展名
.cjs, .js, .mjs, .spec.js, 还有 2 个
打开指南
为什么 TypeScript 页面很重要
许多团队期望借助 TypeScript，终于能够放心地进行 AI 辅助重构。类型系统确实有帮助，但它并没有消除真正的问题：共享包、DTO、生成的客户端、React 组件、测试和应用代码，统统在一个大型代码仓库中引用着相同的名字。
对 TypeScript 而言，标准要高于“它能理解语法”。智能体需要在修改某个共享类型、Hook 或客户端之前，追踪从定义到实现再到影响范围的完整契约链条。
Maguyva 在 TypeScript 中实际提取了什么
Maguyva 会在 .ts、.mts、.cts 以及测试和 Story 周边常见的 TypeScript 文件变体中，提取类、方法、接口和类型别名。成员前缀会被规范化，但类限定的标识符会被保留——这在一个代码仓库同时存在未限定的辅助函数名和末段相同的类作用域方法时会很有帮助。
JSX 被视为真正的结构信号，而不是零散的标记。在已索引的 TypeScript 文件中，测试、Story 和配置仍与应用代码一起可用，帮助智能体在修改共享组件或服务之前检查使用示例和配置。
面向 TypeScript 代码仓库的实用 MCP 工作流
通常三个起手模式就够用了：
- 当你已知接口、类型别名、Hook 或服务名称时，用
find_symbol。 - 在修改可能影响多个包的共享类型或客户端之前，用
dependency_search。 - 当你需要的是代码形态、而不是关键词匹配时（例如重复出现的组件或方法模式），用
structural_search。
对于诸如“追踪结账提交路径”这类概念性问题，get_task_context 往往是比原始搜索更好的第一步。
这个页面在哪些场景下最相关
这个页面最适合 TypeScript 作为多个包协调层的 Web 与平台 Monorepo。如果你的代码仓库仍包含大量较旧的 JS，可以读一读 JavaScript 指南。如果你的问题其实是“智能体能否同时把握应用代码和基础设施上下文”，可以把这个页面和 Terraform 搭配阅读。
最适合场景
- > 在同一个 TypeScript 代码仓库中运行 Next.js、Node 服务、共享包和工具链的产品与平台团队。
- > 接口、DTO、Schema 和 React 组件彼此联动、却分散在不同目录中的代码仓库。
- > 希望在 AI 智能体触碰共享类型或包边界之前，先为其提供安全上下文的团队。
智能体工作流
- > 追踪某个类型、接口或组件，从定义一路到实际使用它的代码路径。
- > 在修改某个共享辅助函数或 API 契约之前，先对比各个包中的实现。
- > 梳理修改某个共享类型、工具函数或服务模块可能带来的影响范围。
引擎细节
- > TypeScript 会提取类、方法、接口和类型别名，而不是把一切都扁平化为通用符号。
- > 成员前缀会被剥离，但类限定标识符会被保留，这有助于区分 `CheckoutService.create` 和未限定的 `create`。
- > JSX 元素被视为实例化。在已索引的 TypeScript 文件中，测试、Story 和配置仍可与应用代码一起提供上下文。
常用 MCP 入口工具
- find_symbol
当你已知想要查看的共享接口、类型别名、hook 或服务时，从这里开始。
- dependency_search
在修改共享 DTO 或客户端前使用，以获得跨包的真实影响范围。
- structural_search
当你需要的是模式匹配而非字符串匹配时，例如重复出现的组件或方法结构，使用 AST 级搜索。