Technical Evaluation

Architecture fit

The package remains a Filament plugin for Laravel applications, now expanding from Filament/Laravel dependency views into application-wide HTTP and View dependency maps.
v1.2.0 adds two scopes that are highly relevant to a TPM: route-to-controller-to-model/policy/event/job/mailable/notification flow, and Blade/Livewire component usage and ownership.
Strong fit for teams already on Laravel 12/13, Filament 4/5, Livewire 3/4, and PHP 8.3–8.5. It complements architecture reviews, onboarding, change-impact analysis, and refactor planning.
The static-analysis approach is a good fit for a developer-facing architecture tool because it avoids instantiating controllers, form requests, policies, components, Livewire classes, or mailables, and does not compile or render templates.

Integration feasibility

Low application-code impact: install via Composer, publish Filament assets, configure scopes, and use the Filament UI or CLI export.
Scopes are opt-in via http and views configuration blocks, plugin methods, and --scope=http|views on the export command.
Snapshot schema is now 1.4; cached snapshots rebuild automatically, reducing upgrade friction.
Suitable for local/staging architecture exploration and CI-generated artifacts. It should not be treated as a runtime dependency map without validating static-analysis coverage.

Technical risk

Static discovery will miss or misrepresent dynamic behavior: dynamic dispatches, container-resolved classes, variable view names, dynamic Blade/Livewire references, polymorphic relationships, and conditional route registration.
The release mitigates some ambiguity with badges such as No reference found / No dispatcher found, missing views, dynamic references, package views as leaves, and inferred view kinds, but these are signals rather than guarantees.
Route cache inclusion is useful, but stale route caches can produce misleading graphs.
Large applications may generate dense graphs; the middleware filter, search by file path, one-hop route-to-view bridge, and scoped exports help, but module-by-module analysis may still be needed.
Exposing the graph in a shared Filament admin can reveal internal architecture; access should be restricted to appropriate engineering roles.
Compatibility is narrow and explicit: PHP 8.3–8.5, Laravel 12/13, Filament 4/5, Livewire 3/4. Version drift must be checked before rollout.

Key questions

Will this run only in local/staging, or will it be exposed in production admin? If production, what Filament authorization gates apply?
Does the target application rely heavily on dynamic dispatch, dynamic view resolution, or runtime container bindings?
Is route caching enabled in the environments where the graph will be used, and how often is it refreshed?
What is the application size and graph density? Do we need module-level exports rather than a full-app graph?
Who owns configuration and access control, and what is the expected workflow for using exports in architecture reviews?

Integration Approach

Stack fit

Confirm PHP 8.3+, Laravel 12/13, Filament 4/5, and Livewire 3/4 before adoption.
Best suited to teams already using Filament for internal tooling; the graph becomes a developer-facing architecture explorer rather than a separate standalone service.
The new HTTP and Views scopes broaden the package from a Filament/Laravel dependency viewer into a cross-cutting application map.

Migration path

Upgrade with composer require laboiteacode/filament-dependency-graph:^1.2 and run php artisan filament:assets.
Publish or update package configuration for http and views blocks, then enable scopes per environment.
Expect automatic snapshot rebuild due to schema 1.4; verify cache behavior in each environment.
If coming from an earlier version, validate that existing Filament and Laravel graph views remain unchanged, then introduce HTTP and Views scopes incrementally.

Compatibility

Livewire 4 single-file and multi-file components are supported, which is important for newer Livewire codebases.
Package views appear as leaves; this is useful for boundary visibility but may add noise in heavily package-dependent applications.
Mermaid edge labels with directives or component tags are now quoted, reducing rendering failures in exported diagrams.
The Filament and Laravel scopes are intentionally unchanged and built without the HTTP/view maps, limiting regression risk in existing views.

Sequencing

Audit PHP, Laravel, Filament, Livewire, and route-cache usage against the compatibility matrix.
Install in local or staging and publish/configure the package.
Restrict Filament access to engineering roles and define whether production exposure is allowed.
Run a baseline full export, then repeat with --scope=http and --scope=views for focused maps.
Validate the graph against known routes, controllers, policies, events, jobs, mailables, Blade templates, and Livewire components.
Pilot on one bounded module or squad before broad rollout.
Integrate exports into onboarding, architecture review, and pre-refactor impact analysis.
Document limitations and review cadence so teams do not over-trust static results.

Maintenance

Low runtime footprint: static discovery, cached snapshot read once per request, and renderer payloads limited to drawn fields.
Maintenance is mainly package upgrades, config ownership, Filament asset rebuilds, and keeping compatibility aligned with Laravel/Filament/Livewire upgrades.
Snapshot schema changes rebuild automatically, but teams should still verify cache clearing and export freshness after upgrades.

Support

Primary support burden is interpretation, not operations: engineers need guidance on static-analysis limits, badges, missing views, dynamic references, and No dispatcher found cases.
A TPM should designate an internal owner for configuration, access control, and onboarding material.
Access control is important because the graph exposes routes, controllers, policies, jobs, mailables, notifications, templates, and component ownership.

Scaling

The package scales better for targeted analysis than for full-application graph reading. Use middleware filters, file-path search, scope-specific exports, and the route-to-view bridge to control density.
For large monoliths, run module-by-module exports and use CLI output as review artifacts rather than relying solely on interactive graph exploration.
Snapshot caching and reduced renderer payloads help request performance, but graph usability at scale remains the main constraint.

Failure modes

Stale route cache can produce outdated HTTP graphs.
Dynamic dispatch, dynamic view references, or runtime-resolved classes can produce false negatives.
Missing or package-provided views may appear as leaves or gaps, requiring manual interpretation.
Misconfigured Filament assets or permissions can make the tool unavailable or over-exposed.
Static graphs may create false confidence during refactor planning if teams treat them as runtime truth.

Ramp-up

Ramp-up is moderate: installation is simple, but teams need training on scope selection, badge interpretation, and static-analysis caveats.
Start with one squad and a known module; measure usefulness in onboarding, impact analysis, and refactor planning before expanding.
Provide a short runbook covering install, config, access control, export commands, cache rebuild expectations, and known limitations.