- What is innmind/object-graph and what is it used for?
- It is a small, framework-agnostic PHP library for modeling object graphs, representing objects and their relationships as nodes and edges. Instead of flattening a structure into an array, it lets you traverse and inspect identity, shared references, and cycles. Typical uses are graph export for documentation, cycle detection in domain models, audit snapshots, and CLI diagnostics. It is a developer-tooling and introspection dependency, not application infrastructure.
- How do I install innmind/object-graph in a Laravel project?
- Install it with Composer as a normal library dependency; it is PSR-4 autoloaded with no framework coupling to reconcile. Laravel 10 and 11 on PHP 8.1 or 8.2+ are compatible at the language level, but verify the package's own PHP constraint against your runtime before pinning. No service provider, config file, or facade ships with it, so if you use it in more than one place, wrap it in a thin internal adapter class and bind that in your own service provider.
- Is innmind/object-graph Laravel-specific or framework-agnostic?
- It is framework-agnostic. Nothing in the package knows about Laravel, Eloquent, facades, or the container, which is why integration is purely additive and requires no migration. That also means you get no auto-discovery, no config publishing, and no Laravel-specific helpers; you supply the glue yourself.
- Does innmind/object-graph work with Eloquent models?
- This is the risky area. Reflection-based traversal handles plain objects, DTOs, value objects, and most domain entities well, but Eloquent adds lazy proxies, relation caches, and magic attributes that can distort or explode the walk. Treat models as a bounded, tested case rather than a default, and prefer running the traversal on DTOs or domain objects when you can. If you must traverse models, write contract tests around the exact model shapes you support.
- How does object graph traversal handle circular references and cycles?
- Cycle handling is precisely the reason to use graph semantics over array flattening, since tree and array serialization loses identity and can recurse forever. The library models identity as nodes with edges, so shared references are represented once rather than duplicated. Because the documented surface is terse, confirm the exact semantics for depth limits, identity by reference versus value, and ordering guarantees in a spike before relying on them. Deep or wide graphs also risk recursion limits and memory spikes, so bound your inputs.
- Can innmind/object-graph export to JSON, DOT, or Graphviz?
- The package produces an internal graph type rather than a serialization format, so you should expect to write the exporter yourself. A common pattern is a visitor or exporter class behind an internal interface such as ObjectGraphExporter, which keeps the dependency swappable and easy to fake in tests. Whether edge labels preserve relationship names or only topology should be checked against the actual API in a spike. If you need DOT output for documentation, that mapping is a small amount of code on your side.
- Is innmind/object-graph fast enough for production request paths?
- No, it is not a hot-path tool. Reflection-heavy traversal is linear in graph size but with high constants, and deep or wide graphs risk recursion limits and memory spikes. It fits bounded, offline or batch tasks such as Artisan diagnostics commands, queue jobs with bounded payloads, test fixtures, and audit snapshots. Keep it out of API resources, session payloads, and anything serving per-request latency budgets.
- Should I use innmind/object-graph instead of Laravel's toArray or JsonResource?
- Use it alongside Laravel serialization, not as a replacement. toArray, JsonResource, and Model relations are the right tools when you want a flat payload for an API response. ObjectGraph earns its place only where graph identity matters, such as detecting cycles or documenting how domain objects reference each other. Do not retrofit it into existing serialization paths; run it in parallel until your adapter has contract tests.
- Is innmind/object-graph safe to depend on in production?
- Vendor risk is real: low star count, few or no known dependents, a single-maintainer ecosystem, and no commercial support mean a low bus factor. The MIT license is the main mitigation, since you can fork and maintain it if upstream stalls. The listed release date is forward-dated relative to typical consumption, so verify actual release cadence and changelog before pinning a version. Keep the dependency behind an internal interface so swapping or forking stays cheap.
- How do I test code that uses innmind/object-graph?
- Because there is no Laravel integration layer, testing is straightforward: construct real object graphs in fixtures and assert on the resulting nodes and edges. Put the library behind an internal exporter or adapter interface so unit tests can substitute a fake and only a small contract test suite touches the real traversal. Cover the edge cases that fail reflection walkers, including cycles, closures, resources, uninitialized typed properties, and internal PHP classes. Also check PHPStan or Larastan behaviour at your configured analysis level, since the API surface is idiosyncratic and documentation is terse.