Download the PHP package hbenabdallah/phpgraph without Composer
On this page you can find all versions of the php package hbenabdallah/phpgraph. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download hbenabdallah/phpgraph
More information about hbenabdallah/phpgraph
Files in hbenabdallah/phpgraph
Package phpgraph
Short Description Knowledge graph builder and query tool for PHP projects, exposed to AI assistants via CLI and MCP
License LicenseRef-PolyForm-Shield-1.0.0
Homepage https://github.com/hbenabdallah/phpgraph
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package phpgraph
phpgraph
A knowledge graph of your PHP codebase, for AI coding agents.
Static analysis served over MCP to Sherpa, Claude Code, Codex, Cursor and any MCP client.
No LLM, no network, no embeddings: deterministic facts, each with a confidence level.
English · Français
Why phpgraph?
An AI agent dropped into an unfamiliar PHP project reads files one by one and greps for names. It misses what matters most in a real codebase: who calls what, which handler receives a message, which controller serves a route, what breaks if a method changes, and which layer depends on which.
phpgraph parses the whole project once (with nikic/php-parser) and answers those questions from a graph:
- Deterministic facts, not guesses. Every relation is
EXTRACTED(read in the code),INFERRED(resolved from declared types) orAMBIGUOUS(a guess, labelled as such). - It says what it does not know. Unresolved calls, missing
vendor/, messages without handlers: the gaps are reported, so the agent knows when to read the code itself. - Built for DDD and hexagonal architecture, then microservices, then PHP in general: Symfony, Laravel, Ecotone, PrestaShop, WordPress, or plain PHP.
- Private by design. Your code never leaves your machine, and phpgraph never executes it: it only parses it.
Features
- Call graph with type inference: return types, chained calls (
$a->b()->c()), local variables, docblocks (@return,@var), and signatures of yourvendor/dependencies, so chains go through Doctrine, Symfony or Laravel APIs. - Architecture: DDD and hexagonal layers, bounded contexts, layer rules checked in CI (
phpgraph check), and impact analysis (impact_of): what depends on a class or method, and which tests to run. - Messages and events: sender → message → handler for Symfony Messenger, Laravel jobs and events, Ecotone, PrestaShop CQRS, WordPress hooks, domain events and your own buses, from attributes, service configuration (YAML, XML, PHP) or code shape.
- HTTP: routes (Symfony attributes, YAML and PHP routing files, API Platform resources, Laravel route files, controllers named by container service id) linked to controllers, and HTTP calls linked to the routes they reach. A route whose controller class exists neither in the project nor in
vendor/is reported with its routing file. - Dependency injection: what the Symfony container configuration injects beyond constructor types, every service of a tag (
tagged_iterator,#[AutowireIterator]) or a service named by id, from PHP, YAML or XML configuration, including helpers called with literal arguments (Wiring::wire($services, 'sales', ...), evaluated, never run): a validator is linked to the rules it receives. A rule declaring what it accepts (supports(object $input): bool { return $input instanceof CreateEstimateQuery; }, alsocanHandle,accepts…) is kept out of the use cases passing another input to the shared pipeline, the classes the input's properties hold included. An input typed by an interface is any project class implementing it and the parameter types it is passed on to (QueryInterface $querygiven tosetUp(CreateEstimateQueryInterface $query): aCreateEstimateQuery); a guard it cannot read, or a rule running for some of these classes only, is kept, markedsupports() not resolved. - Microservices: one id space per service, and links between services through their contracts: shared message classes, routing keys, HTTP routes.
- Zero-configuration MCP server: built on first use, rebuilt incrementally when the code changes (about 3 s per edit on an 8,400-file project).
Quick start
1. Install. A single executable, no PHP needed (Linux and macOS on x86_64 and ARM, Windows on x86_64):
The script downloads the binary, checks its SHA-256 and puts it in ~/.local/bin (Windows: %LOCALAPPDATA%\Programs\phpgraph, added to the PATH); PHPGRAPH_INSTALL_DIR changes the directory. Run it again to update. dev-main is rebuilt on every push to main (the edge pre-release). The binary is a static PHP runtime with phpgraph inside, built with static-php-cli.
With PHP 8.2+ installed, or with Docker:
2. Connect your agent. mcp-config prints a ready-to-paste configuration with the paths filled in (vendor/bin/phpgraph when installed with Composer):
With Sherpa, a terminal coding agent, one declaration in ~/.config/sherpa/mcp.json serves every project: Sherpa starts its MCP servers from the project it runs in.
With Claude Code (absolute paths, as mcp-config prints them):
3. Ask your agent something like "Give me an overview of this project", "How does an order get placed?" or "What breaks if I change OrderRepository::save?". The graph is built on the first call, then kept up to date.
MCP tools
| Tool | Use it to |
|---|---|
overview |
Start here: Composer stack, namespace tree with layers, bounded contexts, layer-rule violations, messages, HTTP routes (each with method, path, controller and file up to 30, else grouped by path prefix), services, and what the graph cannot see. |
query_graph |
Find the code about a topic when you do not know the class names, by the words of their names (validated finds Validator), with the classes of the feature around the ones it names. A question about routes ("mooc courses routes", "GET /courses") returns the matching routes and their controllers. The families of classes around the answer are counted by folder (ContextRuleInterface: 34 in …), injected lists once (ContextValidator receives 34 ContextRuleInterface). |
outline |
Before explaining a feature: its structural outline, enough to read only the few files with non-obvious logic. The classes it is made of, by namespace and layer, with the first sentence of their docblock, their public signatures, constants and enum cases; the interfaces and base classes around it with their implementations by module (0 stated); the routes running into it, chain by chain, through the closures it runs; behaviour read in the bodies (guarded throws, early returns, branches on constants, loop caps, state compared before and after); the container wiring with service ids; its users, tests counted by module, what no test touches and what nothing uses. About 15 KB; a list cut short names the section that has it all (section behaviour, 1 to 9 KB). |
get_node |
Read one class, method, route or channel with all its relations; tests using it are counted by module. |
get_neighbors |
See what uses a node (in) or what it depends on (out). |
impact_of |
Before a change: every class that depends on a class or method, nearest first, with the lines of the calls; callers through the interface it implements; code depending on the state it writes; the routes reaching it, with each chain; and the tests to run, found through test helpers. It flags the classes no test touches and those nothing in the application uses. |
shortest_path |
See how two pieces of code are connected. |
god_nodes |
Find the hubs most of the code depends on. |
The server tells the agent to call overview first. A path, as an agent sees it, on php-ddd-example:
Command line
build options: -e to exclude paths (repeatable), --no-vendor not to read dependencies, --no-cache to parse every file again. vendor, node_modules, var, .git and the files ignored by the project's own .gitignore files are skipped; a git repository above the project never applies its rules, so a project copied into an ignored directory is still read. When the directory holds PHP files but every one is excluded, build fails and says so, and every MCP answer starts with that warning instead of serving an empty graph. Memory is unlimited by default; PHPGRAPH_MEMORY_LIMIT=2G sets a limit. With PHP installed, opcache and its JIT make builds about 20% faster: php -d opcache.enable_cli=1 -d opcache.jit=tracing -d opcache.jit_buffer_size=128M vendor/bin/phpgraph build (the Docker image and the commands printed by mcp-config already use them).
What the graph contains
| Relation | From → to |
|---|---|
defines, imports |
file → class, use statement |
extends, implements, uses_trait |
class → parent, interface, trait |
has_method, overrides |
class → method, method → the method it overrides |
instantiates, references |
new Foo(); parameter, return and property types, catch, instanceof, constants, attributes |
calls |
method → resolved method, with the lines of the call sites; a method running a closure it receives ($apply(...)) calls what the closure calls, INFERRED, via closure of <the method writing it> |
dispatches, handled_by |
sender → message or channel → handler; route → controller; class tested by a supports() method → that strategy |
contract |
a message class sent by one service → the same class handled by another |
requests |
HTTP call → the route it reaches, in the same service or another |
receives |
service → each service the container configuration injects into it (a tag, an id, the decorated service); via says which: service sales.pipeline for one of several services of a class |
reads_state_of |
method → a method of the same class changing a property it reads, outside the constructor (hasErrors() → add()), INFERRED |
Every relation carries a confidence level:
| Level | Meaning |
|---|---|
EXTRACTED |
Read in the code of one file, or in the configuration (attribute, service tag, route file). |
INFERRED |
Resolved across files from declared types: parameters, properties, $this, inheritance, return types, shape of the code. |
AMBIGUOUS |
A guess, for example the only method of the project with that name, called on a receiver of unknown type. |
Frameworks and conventions recognised
| | Handlers and listeners | Messages sent | HTTP | |---|---|---|---| | **Symfony** | `#[AsMessageHandler]`, `#[AsEventListener]`, tags `messenger.message_handler` and `kernel.event_listener` (YAML, XML, PHP, `_instanceof`), `getSubscribedEvents()`, `addListener()` | `MessageBusInterface`, `EventDispatcherInterface`, named events | `#[Route]` (paths in class constants too), YAML and PHP routing files, controllers named by service id; API Platform `#[ApiResource]` and operation attributes, handled by their provider, processor or controller | | **Laravel** | `$listen`, `Event::listen()`, jobs (`ShouldQueue`, `Dispatchable`) | `event()`, `dispatch()`, facades, `Job::dispatch()` | `Route::get/post/…`, `match`, `resource`, groups with `prefix`, `routes/api.php`; `Http::` client | | **Ecotone** | `#[CommandHandler]`, `#[EventHandler]`, `#[QueryHandler]`, routing keys | `CommandBus`, `EventBus`, `DistributedBus`, `sendWithRouting()` | | | **PrestaShop** | `#[AsCommandHandler]`, `#[AsQueryHandler]` | `CommandBusInterface::handle()` | YAML routing | | **WordPress** | `add_action()`, `add_filter()` | `do_action()`, `apply_filters()` | | | **Your own code** | handler attributes and tags recognised by name, `__invoke`/`handle(Message $m)`, `*Handler` classes | `*Bus`, `*Dispatcher`, `*Publisher` types, aggregates' `recordThat()`, your bus wrappers | Guzzle, Symfony HttpClient, PSR-18 |Architecture: layers, bounded contexts, rules in CI
The layer of a class is read from its namespace: the first explicit segment (`Domain`, `Application`, `Infrastructure`, `UI`, `Presentation`, `Port`, `Adapter`, `UseCase`), or else the last generic one (`Model`, `Entity`, `Controller`, `Http`, `Persistence`…). The bounded context is read before the layer (`CodelyTv\Mooc\Courses\Domain`) or after it when the project puts the layer first (`Core\Domain\Product`). `phpgraph check` applies the default rules of a layered architecture to application code: `domain` must not depend on `application`, `infrastructure` or `interface`; `application` and `port` must not depend on `infrastructure` or `interface`. On a project that already has violations:Microservices
A repository holding two or more independent Composer applications is split into services. Packages of a monorepo stay in their project: a package the root autoloads, declares as a path repository or `replace`s is a part, not a service. Ids then carry their service, `billing@App\Domain\Order`, and a name never resolves into another service: services meet through contracts. - the same message class sent by one service and handled by another: `contract`; - a routing key (`sendWithRouting('order.place', …)`, `#[CommandHandler('ticket.create')]`, a named event): a `channel:` node shared by all services; - an HTTP call to a route of another service: `requests`. A call whose path matches a route declared for other HTTP methods only is reported: it would fail as written. An optional `phpgraph.yaml` names the services when detection does not fit:How it works
1. Every PHP file is parsed into facts: declarations, calls with the expression typing their receiver, message sends and handlers, routes, HTTP calls. 2. The builder resolves those facts across files: types through inheritance and return types, `vendor/` signatures read on demand from Composer's metadata (parsed, never executed), service definitions from the container configuration. 3. The graph is saved as `phpgraph-out/graph.json`, with `GRAPH_REPORT.md` for humans. Rebuilds are incremental: a file's extraction is cached by content, and the MCP server re-resolves only the calls of changed files when no declaration changed anywhere. The result is identical to a full build.Measured on real projects
phpgraph is developed against a corpus of open-source projects pinned to a commit, and every change is judged on their numbers (composer corpus:measure). Application code only; receiver typed is the share of method calls whose receiver type phpgraph could determine.
| Project | Kind | PHP files | Build | Receiver typed |
|---|---|---|---|---|
| php-ddd-example | DDD, CQRS | 304 | 0.4 s | 98.3 % |
| Sylius | Symfony e-commerce | 4,946 | 6.5 s | 79.6 % |
| Akeneo PIM | hexagonal, bounded contexts | 8,416 | 10.3 s | 87.0 % |
| PrestaShop | CQRS and legacy | 7,850 | 10.0 s | 90.5 % |
| Ecotone quickstart | 47 services, messaging | 583 | 0.6 s | 91.8 % |
| BookStack | Laravel | 1,513 | 2.8 s | 87.4 % |
| WordPress | no framework, hooks | 1,899 | 5.3 s | 90.9 % |
Two small microservices projects complete the corpus: two Laravel services over RabbitMQ, linked by 4 message contracts, and four Laravel services over HTTP, where phpgraph found a POST sent to a GET-only route. Zero parse failures on about 26,000 files. The details per project, including messages, routes and services, are in corpus/RESULTS.md.
With an agent
Measured on a private 4,800-file Symfony/DDD project, 3 runs per setup, the same agent (Sherpa) with and without phpgraph 1.0.2:
| Kind of question | With phpgraph | Quality |
|---|---|---|
Impact or refactoring (impact_of) |
−42 % tokens, −50 % time, −59 % tool calls | same or better |
Explaining a feature (outline) |
−25 % tokens, −34 % time, −49 % tool calls; −31 % tokens with the default outline | same |
The ranges of the runs with and without phpgraph do not overlap.
Compared with other code graphs
Sylius (the corpus commit), October 2026, without any LLM: phpgraph 1.0.2, codebase-memory-mcp 0.11.0 and graphify 0.9.76 (--code-only), on the same machine, in Docker. The calls were compared site by site (file, line, method), and samples of the differences were checked in the code.
| phpgraph | codebase-memory-mcp | graphify | |
|---|---|---|---|
| Build | 10 s | 17 s | 32 s |
| Call sites linked to a project method | 22,870 | 32,274 | 4,005 |
| of which resolved from types | 22,747 | 4,314 | — |
Callers of OrderItemQuantityModifierInterface::modify() found (17 in the code) |
17, no false one | 11, 2 false | 0, 1 false |
| Messenger handlers linked to their message | 206 | 0 | 0 |
| Container injections, routes | 1,360, 188 | 0, 1 (false) | 0, 0 |
- codebase-memory-mcp agrees with phpgraph on 99.7 % of the calls it resolves from types. The rest of its edges are guessed from the method name (confidence 0.04 to 0.44): where both link the same call, they disagree on 9,400 sites, and its 11,300 extra edges are mostly calls into
vendor/attached to a project method of the same name (19 of 20 checked). - graphify links
$this->other->foo()tofoo()of the current class: right for$this->foo(), wrong for the 10 of 10 differences checked. - What they have and phpgraph has not: other languages, full-text and vector search, Cypher queries (codebase-memory-mcp), an interactive visualisation and documents in the graph (graphify).
FAQ
Does phpgraph send my code anywhere? No. It runs locally, makes no network call and uses no LLM.
Does it execute my code? No. It parses PHP files and reads JSON, YAML and XML configuration. Even autoload_classmap.php and PHP service configurators are parsed, not included.
Which PHP versions can it analyse? Anything nikic/php-parser 5 parses: PHP 7 and 8 syntax. phpgraph itself needs PHP 8.2 or newer.
Which agents does it work with? Any MCP client over stdio: Sherpa, Claude Code, Codex, Cursor, Claude Desktop, and others. mcp-config prints the configuration for the common ones.
How large a project can it handle? The largest project of the corpus, Akeneo, has 8,400 files: about 10 s and 500 MB for a full build, about 3 s for a rebuild after an edit.
Limitations
- Calls to global functions and dynamic calls (
$this->$name(),__call) are not resolved. - Generics are read for collections only: a
foreachover a parameter or property documented asFoo[],array<Foo>,list<Foo>oriterable<Foo>is typed;Collection<Foo>and other generic classes are read asCollection. - Chains stop at magic methods, PHP internal classes, and dependencies without a usable return type.
- Without an installed
vendor/, call chains stop at the first dependency. - Services built at runtime (compiler passes, bundle extensions, ids computed from values only known at runtime), XML routes, API Platform resources declared in XML or YAML, and API schemas (OpenAPI, protobuf) are not read; injections that cannot be linked are listed by
overview. - Two services declaring a message class of the same name are assumed to share it.
Contributing
Issues and pull requests are welcome. See CONTRIBUTING.md: composer check must pass (php-cs-fixer, PHPStan level 8, PHPUnit), and changes to the analysis are judged on the corpus. Without PHP installed, bin/dev composer check runs everything in Docker.
What stays stable across versions (commands, MCP tools, the graph.json format) is listed in docs/STABILITY.md; changes are in the changelog.
Releases are published by pushing a version tag: the release workflow builds the PHAR, the executables for Linux, macOS and Windows (tools/build-binary.sh), and the Docker image ghcr.io/hbenabdallah/phpgraph.
License
phpgraph is source-available under the PolyForm Shield License 1.0.0: you may use, modify and redistribute it, including in a company, for any purpose that does not compete with phpgraph. Providing a competing product from this code is not allowed. This is not an OSI-approved open-source license.
All versions of phpgraph with dependencies
nikic/php-parser Version ^5.0
symfony/console Version ^7.0
symfony/finder Version ^7.0
symfony/yaml Version ^7.4