Filament Dependency Graph Laravel Package

Product Decisions This Supports

• Refactor and modernization sequencing. Before committing a roadmap item like "extract billing into a module" or "migrate Blade views to Livewire," the HTTP and Views scopes give a defensible blast-radius estimate: which routes hit which controller actions, which models and policies those actions touch, which jobs/mailables/notifications fire downstream, and which templates and components those flows render. That converts "this feels risky" into a scoped, reviewable list.
• Build vs. buy for internal architecture tooling. Until now, most teams answer these questions with a spreadsheet, a senior engineer's memory, or a bespoke script that rots. This package is a cheap buy that replaces the bespoke script, and it is a dev-only dependency — no production surface, no data pipeline, no instrumentation to maintain.
• Impact analysis as a standing capability, not a one-off. Because discovery is static and the snapshot is cached and rebuilt automatically, the graph can sit in the team's normal workflow (Filament admin panel, CLI export, Mermaid diagrams in a design doc or PR) rather than being a quarterly archaeology exercise.
• Deprecation and surface-area decisions. The route→view bridge, "missing views," "no dispatcher found," and "no reference found" badges are direct evidence for pruning: dead routes, orphaned templates, listeners nothing dispatches, controllers nobody routes to. That is a roadmap input ("remove legacy reporting UI in Q3") with an audit trail attached.
• Onboarding and knowledge-transfer cost. A map of routes, controllers, components and their owners shortens time-to-first-meaningful-PR for new engineers and reduces the bus factor concentrated in one or two long-tenured developers.
• Scope-boundary conversations with stakeholders. View owners (Livewire render(), #[Layout], conventional layouts, Filament custom $view, mailables, Route::view/Route::livewire) make ownership visible. Useful when negotiating team boundaries or arguing that a "small UI change" is actually cross-cutting.

When to Consider This Package

Adopt when most of the following hold:

• The application is Laravel 12 or 13 on PHP 8.3–8.5, and you already run Filament 4/5 (the plugin lives in the panel, so Filament is the delivery surface) with Livewire 3/4 if the Views scope matters to you.
• You have a monolith of nontrivial size — enough routes, controllers and templates that no one person holds the whole map. Below a few dozen routes the graph costs more attention than it saves.
• You are planning or mid-flight on a structural change: modularization, Inertia/Livewire migration, package extraction, or a legacy-area rewrite.
• You want static answers with zero runtime risk: nothing is instantiated, no template compiled or rendered, no request replayed. That is the property that makes it safe to point at production-shaped code and safe to put in front of skeptical engineers.
• You need artifacts — exports, Mermaid diagrams, file:line references — for design docs, ADRs, or review checklists, not just an interactive toy.

Look elsewhere, or treat it as partial, when:

• You need runtime truth. This is static and explicitly one level deep into injected application classes. Dynamic resolution, container bindings built at runtime, view() called with a computed name, or dispatch through variables will show up as dynamic references or "no reference found." For real traces, pair it with Telescope, Xdebug or a profiler.
• You need correctness gating in CI. This is an explorer, not a linter. PHPStan/Larastan and Pest/PHPUnit remain your quality gates; do not let a graph substitute for them.
• You are not on Laravel/Filament, or you are pinned to older majors — the compatibility window is narrow and explicit.
• You need static analysis of your own domain logic (service classes, repositories, queues beyond dispatch sites). Out of scope; the HTTP scope stops at the controller action plus one level of injection.
• Very large codebases with tight page budgets. The release notes promise the snapshot is read once per request and the renderer only receives fields it draws, and that Filament/Laravel scopes are now built without the HTTP/view maps — good signs, but treat explorer responsiveness on your largest app as an acceptance criterion, not an assumption.
• You require vendor support contracts or a guaranteed API. Note the internal changes: snapshot schema is now 1.4 with automatic cache rebuild, and the Filament/Laravel scopes are built without HTTP and view maps. If you have custom plugins or code reading the snapshot, budget a verification pass.

How to Pitch It (Stakeholders)

For executives: We have a recurring, expensive problem — nobody can say with confidence what a change will touch until an engineer spends days tracing it. This adds two new maps to an existing dev-only tool: one for HTTP (route → controller → form request → model → policy → event/listener → job/mailable/notification) and one for views (Blade templates, components and Livewire, plus what renders them and where they are used). It is read-only, static, and never executes our code — controllers are not instantiated, templates are not compiled. Cost is a Composer dependency; the return is faster, better-scoped estimates on refactors and a defensible list of dead code we can retire.

For engineering: It answers the questions you currently answer from memory. Middleware is resolved the way the router resolves it and is filterable in the explorer, in GraphQuery::$middleware, and via --middleware on export. Dispatches and model references are detected statically with file:line locations, one level deep into injected classes. The Views scope reads @extends, the @include family, @each, @component, @livewire, <x-…> and <livewire:…> with line numbers, resolved through the view finder, Blade's component tag compiler and Livewire's registry — and it handles Livewire 4 single-file and multi-file components. Package views are treated as leaves so vendor code does not pollute the map. Form request rule reading is opt-in (http.form_request_rules) because it is the one place where scope creeps.

Constraints to state up front, so nobody is surprised: it is static, so treat gaps as questions rather than answers — the "no reference found" and "no dispatcher found" badges mean we could not see it statically, which is itself useful signal about dynamic magic in the codebase. Filament and Laravel scopes are unchanged and now deliberately exclude the HTTP and view maps, so existing views of those scopes stay stable. The snapshot schema moved to 1.4 and caches rebuild automatically on upgrade; expect a one-time warm-up. Requires PHP 8.3+, Laravel 12/13, Filament 4/5, Livewire 3/4 — confirm we are inside that window before we commit. Ship it as a dev dependency, verify explorer performance against our largest panel, and use it to produce one Mermaid diagram for a real upcoming decision as the pilot.