Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Feature request: expose owning-manifest lookup (nearest manifest with a name, per file)

Open
  • Is something wrong?
#1,871 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
c
Domain
cli, tooling

Research direction

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.

Written by the indexing model from the issue text.

Description

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 in files, no file node).
  • There's no package node kind, and no package/manifest concept anywhere in the nodes schema.
  • codegraph files --format grouped groups 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 their name field.
  • 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.json over composer.json).
  • Expose this as a query, both CLI (e.g. codegraph package-of <file> or a --group-by-package mode on files) 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.

Dominant language
C
Stars
73.2k
Forks
4.7k
Avg merge
2h 13m
Merged PRs (30d)
418

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from colbymchenry/codegraph

All issues in colbymchenry/codegraph

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.