Feature request: expose owning-manifest lookup (nearest manifest with a name, per file)
维护者通常 1 天内回复
评估
调研方向
Start by reading the index and nodes schema, then inspect the codegraph files CLI command and the MCP tool entry points. The issue proposes indexing named manifests and resolving ownership via the nearest ancestor manifest, with a deterministic tie-break. Done means the lookup is exposed through CLI and MCP and clearly reports when no owning package exists; manifest formats needing real parsing are explicitly deferred.
由索引模型根据 Issue 内容生成。
描述
Several use cases need "which package owns this file" as a graph query instead of a hand-rolled resolver: sharding a set of changed files by package for parallel review or build agents, or other workspace-aware tooling.
CodeGraph doesn't have this today. Checked against an example project's live index (a PHP codebase, 179 files):
- Manifest files (e.g.
package.json,composer.json) aren't indexed as files at all (no row infiles, nofilenode). - There's no
packagenode kind, and no package/manifest concept anywhere in thenodesschema. codegraph files --format groupedgroups by language, not by owning package.
Proposed shape, based on a bash implementation we maintain today as a stopgap:
- Index manifest files (e.g.
package.json,composer.json) for at least theirnamefield. - Given a file path, resolve its owning package by walking ancestor directories for the nearest manifest with a non-empty
name. This also handles monorepos and workspaces without extra config. Each subpackage's own manifest is nearer to its files than the root manifest, so the walk resolves to the right package on its own. When two different manifest types are found at the same distance, pick a deterministic winner (e.g.package.jsonovercomposer.json). - Expose this as a query, both CLI (e.g.
codegraph package-of <file>or a--group-by-packagemode onfiles) and MCP tool, returning the package name or a clear "no owning package" result for files with none above them.
Manifest formats needing real parsing rather than a name-key grep (Cargo.toml, pyproject.toml) can follow later; a naive name = match would mis-group files.
- 主要语言
- C
- 星标
- 73.2k
- 派生
- 4.7k
- 平均合并
- 4 小时 53 分钟
- 30 天内合并 PR
- 626
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
colbymchenry/codegraph 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
colbymchenry/codegraph#1900 · 2 条评论 · 5 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
colbymchenry/codegraph#1700 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
colbymchenry/codegraph#1535 · 2 条评论 · 2 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 63/100
colbymchenry/codegraph#1403 ·
维护者通常 1 天内回复
-
agent-target
难度 2/5 1-3 小时 新手友好度 68/100
colbymchenry/codegraph#649 · 5 条评论 · 50 个 reaction ·
维护者通常 1 天内回复
查看 colbymchenry/codegraph 的全部 Issue
相似的 Issue
-
difficulty: easy
难度 2/5 1-3 小时 新手友好度 64/100
-
难度 2/5 1-3 小时 新手友好度 65/100
-
performance solver
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
ChefKissInc/Inferno#319 ·
-
llvm-tools
难度 1/5 1 小时以内 新手友好度 72/100
llvm/llvm-project#235522 ·
维护者通常 1 天内回复