jevgrep 解析黑科技WASM 辅助 worker 如何高效提取 Python/TypeScript 声明与调用链【免费下载链接】jevgrepFind code by asking what it does. A CLI for coding agents that uses Jev to discover relevant files and source context.项目地址: https://gitcode.com/gh_mirrors/je/jevgrepjevgrep是一个面向编码智能体Coding Agent的代码检索 CLI你用它问这段代码是做什么的它返回相关文件、源码摘录和声明/调用位置。而它最硬核的部分是在无需安装 Python 的前提下用 WASM 运行时 Node worker 高效提取 Python 与 TypeScript 的声明结构和调用链。本文将拆解这套机制的设计思路。为什么需要 WASM 辅助的声明提取编码智能体处理陌生任务时很大一部分时间花在找到正确的文件。jevgrep 的jg命令按层级遍历仓库、用 Jev 模型判断目录/文件/声明的相关性最终输出带行号的源码片段作为证据。问题在于要精准切出函数体类头方法区间必须做真正的语法解析而不是正则猜测。Python 用官方ast模块最可靠——但用户机器上未必有 Python。jevgrep 的解法是把整个 CPython 解释器编译成 WebAssembly即 Pyodide塞进一个 Node 子进程里跑从而做到零系统依赖的源码解析。架构拆解一个序列化解释器 四个辅助程序整个 Python 解析路径由两部分组成父进程侧python.ts 用fork启动 worker 子进程通过 IPC 以请求 ID 辅助程序名 源码文本的方式发送任务收到对应 ID 的响应后解除 Promise。Worker 侧python-worker.mjs 加载 Pyodide 运行时一次性把 4 个内置.py辅助程序compile成代码对象之后每条请求只是换 stdin、重定向 stdout、exec对应程序。四个辅助程序分工明确源码位于 packages/core/assets/python/辅助程序职责inspect.py提取声明边界函数/方法/类的起止行含装饰器、类头区间ownerHeaders支持嵌套类preview.py按查询词生成查询辅助内容窗口在字节预算内分配开头上下文、命中声明头、实现体等片段neighborhood.py为选中的方法补充结构性上下文类头 相邻方法≤40 行calls.py提取self.method(...)调用链按 MRO 解析继承方法定义调用链提取的黑科技手写 MRO 线性化calls.py 的亮点在于它自己实现了 C3 线性化算法来计算类的方法解析顺序MRO而不是简单按继承链线性查找对每个纯净方法首参为self、无装饰器、无自赋值扫描其调用点中的self.xxx(...)沿 MRO 逐层查找目标方法定义跳过同名基类冲突与重复项检测继承环与不一致 MRO输出包含调用者、目标方法、行区间、未知基类unknownEarlierBases与所属类头供后续选取上下文。这让 agent 在看到调用、追不到定义的继承场景里也能拿到确定的阅读线索——注意它的注释这是静态阅读线索而非运行时派发证明定位很克制。TypeScript 走原生编译 API不浪费 WASMTypeScript/JavaScript 的声明提取没有走 worker而是直接在 Node 进程内调用 TypeScript 编译器 APIsource.ts 用ts.createSourceFile建 AST递归提取类、方法、变量声明的行号区间与字节偏移并检查parseDiagnostics决定是否降级为文本分块。语言各用最优路径PythonWASM 里的 CPythonast语法权威性最高TS/JS进程内 TS 编译器零开销其他文本按字节预算切分的有界文本块兜底。几个提升效率与稳健性的工程细节懒启动 空闲自杀worker 只在首次需要时 fork空闲时unref不会阻止 CLI 进程退出也避免孤儿进程worker 侧监听disconnect主动退出。单一序列化解释器所有 Python 请求排队串行进入同一个解释器WASM 运行时只初始化一次辅助程序只编译一次。取消安全取消信号会终止当前解释器但无副作用的解析请求会被重新调度到新解释器上继续完成不浪费已排队的任务。错误降级而非崩溃辅助程序内的异常被捕获为sourceError如SyntaxError上层据此回退到文本分块模式解析不可用 ≠ 文件不可用。信任边界清晰worker 只执行打包内置的辅助程序仓库内容永远只是 stdin 数据不存在解析用户代码执行用户代码的风险。相关文件速查架构总览docs/architecture.mdPython worker 调度packages/core/src/python.tsWASM 运行时入口packages/core/src/python-worker.mjs声明/调用链解析packages/core/assets/python/inspect.py、packages/core/assets/python/calls.py辅助程序说明与许可证packages/core/assets/README.md、scripts/licenses/想亲手验证的话可克隆仓库阅读源码需 Node.js 22git clone https://gitcode.com/gh_mirrors/je/jevgrep一句话总结这套设计WASM 提供了处处可跑的 CPythonworker 提供了隔离与懒加载四个小型辅助程序把 AST 能力切成可编排的乐高积木——解析能力、执行安全和进程生命周期三者兼得这正是 jevgrep 能开箱即用、零 Python 依赖的关键。【免费下载链接】jevgrepFind code by asking what it does. A CLI for coding agents that uses Jev to discover relevant files and source context.项目地址: https://gitcode.com/gh_mirrors/je/jevgrep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
jevgrep 解析黑科技WASM 辅助 worker 如何高效提取 Python/TypeScript 声明与调用链【免费下载链接】jevgrepFind code by asking what it does. A CLI for coding agents that uses Jev to discover relevant files and source context.项目地址: https://gitcode.com/gh_mirrors/je/jevgrepjevgrep是一个面向编码智能体Coding Agent的代码检索 CLI你用它问这段代码是做什么的它返回相关文件、源码摘录和声明/调用位置。而它最硬核的部分是在无需安装 Python 的前提下用 WASM 运行时 Node worker 高效提取 Python 与 TypeScript 的声明结构和调用链。本文将拆解这套机制的设计思路。为什么需要 WASM 辅助的声明提取编码智能体处理陌生任务时很大一部分时间花在找到正确的文件。jevgrep 的jg命令按层级遍历仓库、用 Jev 模型判断目录/文件/声明的相关性最终输出带行号的源码片段作为证据。问题在于要精准切出函数体类头方法区间必须做真正的语法解析而不是正则猜测。Python 用官方ast模块最可靠——但用户机器上未必有 Python。jevgrep 的解法是把整个 CPython 解释器编译成 WebAssembly即 Pyodide塞进一个 Node 子进程里跑从而做到零系统依赖的源码解析。架构拆解一个序列化解释器 四个辅助程序整个 Python 解析路径由两部分组成父进程侧python.ts 用fork启动 worker 子进程通过 IPC 以请求 ID 辅助程序名 源码文本的方式发送任务收到对应 ID 的响应后解除 Promise。Worker 侧python-worker.mjs 加载 Pyodide 运行时一次性把 4 个内置.py辅助程序compile成代码对象之后每条请求只是换 stdin、重定向 stdout、exec对应程序。四个辅助程序分工明确源码位于 packages/core/assets/python/辅助程序职责inspect.py提取声明边界函数/方法/类的起止行含装饰器、类头区间ownerHeaders支持嵌套类preview.py按查询词生成查询辅助内容窗口在字节预算内分配开头上下文、命中声明头、实现体等片段neighborhood.py为选中的方法补充结构性上下文类头 相邻方法≤40 行calls.py提取self.method(...)调用链按 MRO 解析继承方法定义调用链提取的黑科技手写 MRO 线性化calls.py 的亮点在于它自己实现了 C3 线性化算法来计算类的方法解析顺序MRO而不是简单按继承链线性查找对每个纯净方法首参为self、无装饰器、无自赋值扫描其调用点中的self.xxx(...)沿 MRO 逐层查找目标方法定义跳过同名基类冲突与重复项检测继承环与不一致 MRO输出包含调用者、目标方法、行区间、未知基类unknownEarlierBases与所属类头供后续选取上下文。这让 agent 在看到调用、追不到定义的继承场景里也能拿到确定的阅读线索——注意它的注释这是静态阅读线索而非运行时派发证明定位很克制。TypeScript 走原生编译 API不浪费 WASMTypeScript/JavaScript 的声明提取没有走 worker而是直接在 Node 进程内调用 TypeScript 编译器 APIsource.ts 用ts.createSourceFile建 AST递归提取类、方法、变量声明的行号区间与字节偏移并检查parseDiagnostics决定是否降级为文本分块。语言各用最优路径PythonWASM 里的 CPythonast语法权威性最高TS/JS进程内 TS 编译器零开销其他文本按字节预算切分的有界文本块兜底。几个提升效率与稳健性的工程细节懒启动 空闲自杀worker 只在首次需要时 fork空闲时unref不会阻止 CLI 进程退出也避免孤儿进程worker 侧监听disconnect主动退出。单一序列化解释器所有 Python 请求排队串行进入同一个解释器WASM 运行时只初始化一次辅助程序只编译一次。取消安全取消信号会终止当前解释器但无副作用的解析请求会被重新调度到新解释器上继续完成不浪费已排队的任务。错误降级而非崩溃辅助程序内的异常被捕获为sourceError如SyntaxError上层据此回退到文本分块模式解析不可用 ≠ 文件不可用。信任边界清晰worker 只执行打包内置的辅助程序仓库内容永远只是 stdin 数据不存在解析用户代码执行用户代码的风险。相关文件速查架构总览docs/architecture.mdPython worker 调度packages/core/src/python.tsWASM 运行时入口packages/core/src/python-worker.mjs声明/调用链解析packages/core/assets/python/inspect.py、packages/core/assets/python/calls.py辅助程序说明与许可证packages/core/assets/README.md、scripts/licenses/想亲手验证的话可克隆仓库阅读源码需 Node.js 22git clone https://gitcode.com/gh_mirrors/je/jevgrep一句话总结这套设计WASM 提供了处处可跑的 CPythonworker 提供了隔离与懒加载四个小型辅助程序把 AST 能力切成可编排的乐高积木——解析能力、执行安全和进程生命周期三者兼得这正是 jevgrep 能开箱即用、零 Python 依赖的关键。【免费下载链接】jevgrepFind code by asking what it does. A CLI for coding agents that uses Jev to discover relevant files and source context.项目地址: https://gitcode.com/gh_mirrors/je/jevgrep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
