Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#1,871 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c
Ambito
cli, tooling

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
C
Stelle
73.2k
Fork
4.7k
Merge medio
2h 13m
PR unite (30g)
418

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di colbymchenry/codegraph

Tutte le issue di colbymchenry/codegraph

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.