Filament Reports Laravel Package

Technical Evaluation

Architecture fit. eightynine/filament-reports is a Filament panel plugin, which means it slots into the standard Laravel package contract: a service provider, a Plugin class registered on a PanelProvider, publishable config/views/migrations, and report definitions expressed as PHP classes rendered as Filament pages or widgets. For a team already running Filament as its admin surface, this is the lowest-friction shape a reporting add-on can take — no separate frontend, no second auth system, and report screens inherit the panel's existing navigation, policies, and tenancy scoping. The architectural question is not "does it fit Laravel" (it does, by construction) but whether the package's report abstraction is a definition layer over your models (good — thin, portable, testable) or a parallel query DSL (riskier — logic lives in vendor-shaped classes and is harder to unit test or move off later). Confirm which before committing. Release 4.0.0 does not touch this question — it is a compatibility release, not a redesign — so the answer must still come from reading the source in a spike.

Integration feasibility. Composer install, ->plugin(FilamentReportsPlugin::make()) on the panel, publish config, optionally publish migrations if report definitions or saved filters are persisted. Realistic effort for a first working report is hours, not days. The binding constraints are version compatibility (Filament major, Laravel major, PHP minor, Livewire) and asset publishing — Filament v3+ ships its own compiled CSS, so a plugin whose views assume a different Tailwind/Filament build can render subtly broken until assets are published and rebuilt. Both are verified in a spike, not from the README. 4.0.0 changes the compatibility arithmetic: the package now versions in lockstep with Filament majors (3.x ↔ Filament v3, 4.x ↔ Filament v4), so "which version do I install" is now a function of the host panel's Filament major, not a free choice. Confirm the target panel's Filament version before anything else, and confirm whether the 3.x line continues to receive fixes for teams not yet on Filament v4.

Technical risk.

• Version coupling — now lockstep. Filament ships breaking majors on a roughly annual cadence, and plugins that touch panel internals, page classes, or table/resource APIs break at each one. 4.0.0 is evidence the maintainer tracks Filament releases, which is a genuine positive signal and materially better than silence. It is also one data point: the v4 code path is brand new, has no production mileage, and was written against Filament v4's own freshly-changed APIs. The coupling risk is unchanged in kind and slightly increased in surface — you now inherit Filament's upgrade clock on both sides of the dependency.
• Bus factor and ecosystem signal. Still the headline risk. Low stars and 0 dependents means the package is not meaningfully exercised in production by anyone the registry can see. There is no downstream corpus to absorb upgrade pain, no volume of filed issues documenting edge cases, and no community pressure to fix them — and the v4 branch in particular has had no such exposure at all. Treat it as "source-available code you are adopting," not "a dependency you are consuming."
• Two supported majors, one maintainer. 4.0.0 implies a 3.x branch that still exists for Filament v3 users. With a single maintainer, supporting two Filament majors simultaneously means every future fix needs a backport decision, and backports are the first thing to stop. Assume 3.x is on a de facto freeze and that adopting this package is an argument for being on Filament v4.
• SQL surface. Report builders compose selectRaw, aggregate expressions, and date truncation. That is an injection-adjacent surface if any user-supplied filter or column name reaches raw SQL, and a correctness surface across MySQL/Postgres/SQLite (date functions, GROUP BY strictness, timezone handling) even when it doesn't.
• Data-volume behavior. Report pages typically load eagerly and synchronously inside a Livewire request. Unbounded tables, wide date ranges, and exports are the classic failure point. A Filament v4 jump also means a Livewire major jump underneath it, which changes component lifecycle and request handling — a place where this class of bug tends to appear.

Key questions.

1. Which Filament and Laravel majors are supported? Partially answered by 4.0.0: Filament v4 is supported via ^4.0; Filament v3 remains on the 3.x line. Still open: exact Laravel/PHP/Livewire matrix, and the maintainer's stated policy for future Filament majors.
2. Is the 3.x branch still maintained — will it receive security and bug fixes, and for how long? Or is 4.0.0 a de facto "upgrade or fend for yourself" signal?
3. Does 4.0.0 adopt Filament v4's tenancy/scoping APIs natively, or shim them? Filament v4 changed schema and panel APIs; the tenancy behavior is the thing most likely to regress silently across a major.
4. Are there breaking changes within the package's own report-definition contract between 3.x and 4.0.0, or is it a pure compatibility bump? Read the diff, not the release note — the note is one line.
5. Are report definitions app-owned classes with a documented base contract, or config arrays interpreted by the package?
6. Does it support queued/streamed exports (CSV/XLSX/PDF), or is export synchronous in-request?
7. How are filters parameterized — bound parameters, or interpolated into raw SQL?
8. Is there a persistence schema (saved reports, runs, schedules) that becomes ours to migrate, and did 4.0.0 change it?
9. Test coverage and CI matrix — is the v4 compatibility actually verified in CI, or asserted in a one-line changelog?

Integration Approach

Stack fit. Only relevant if the target application is Laravel + Filament on a supported PHP version. If the team is on Nova, Backpack, or a bespoke admin, this package is a non-starter and the "opportunity" score is irrelevant. Confirm the Filament version of the target panel first; that single fact now gates both whether you can use the package and which major you install:

• Filament v3 panel → plugin 3.x, and accept that you are on the branch most likely to be frozen.
• Filament v4 panel → plugin 4.x, on a code path with no production mileage anywhere yet.
• Mid-migration panels → you cannot straddle this; sequence the Filament v4 upgrade and the plugin adoption together.

Migration path. Adopt behind an internal seam. Register the plugin, but define reports as application classes under app/Reports/ implementing the package's contract, with a thin internal base class or interface in front of it. That way an upstream break, a 3.x→4.x jump, or a decision to swap to a hand-rolled Filament page is a change in one directory rather than a rewrite of every report. Pin the exact version in composer.json (no caret on a low-star plugin with a single maintainer), commit the lockfile, and record the adopted commit SHA. Pin the pair — record the plugin major alongside the Filament major it was validated against, because that mapping is now the compatibility contract. If any publishable migrations exist, review the schema and own it — published migrations are yours forever regardless of what upstream does next, and a 4.0.0 migration diff needs reading even if the version note doesn't mention one.

Compatibility. Verify explicitly: composer why-not against the target Filament/Laravel/PHP versions; the Livewire major (v3 vs v4 changes component lifecycle, and Filament v4 drags it along); database driver(s) actually in use, with at least one report exercised against each; and asset rendering in the real panel (dark mode, RTL if relevant, Filament theme customizations). Check whether the plugin's views are precompiled or need npm run build in the host app — a Filament-major-aligned release is exactly when compiled assets and Tailwind class names get rebuilt and drift. For 4.0.0 specifically, diff 3.1.0...4.0.0 before installing; a one-line release note is not a migration guide.

Sequencing.

1. Decide the Filament major first. If the target panel is on v3 and staying there for a year, this package's 4.0.0 release is not available to you in practice — plan around 3.x or defer.
2. Spike (1–2 days). Throwaway branch, one non-trivial report against production-shaped data, on the Filament v4 + plugin 4.x pair if that is the destination. Answers the architecture question and surfaces asset/version issues cheaply.
3. Version pin + fork readiness. Mirror the repo internally (or vendor it), set up Renovate/Dependabot with the plugin excluded from automerge, and confirm someone can build and test a fork — including building and testing a fork against the next Filament major, which 4.0.0 tells you will arrive.
4. Authorization and tenancy. Re-verify explicitly on v4, do not assume v3 behavior carried over. Wire reports into the panel's policy and tenancy model before any report is exposed to a non-admin. This is the step most likely to be skipped and most likely to matter.
5. Performance hardening. Establish a row/time budget per report, add indexes, move exports to queues, cap date ranges.
6. Rollout. Internal/admin-only first, then broader roles once failure modes are observed.

Operational Impact

Maintenance. Plan for ownership, not consumption. The realistic steady state is: minor version bumps are safe, Filament majors require a fork patch that you write and upstream (best case) or carry (likely). The good news from 4.0.0 is that the maintainer did the work this cycle, on time, for a current Filament major — that is the single most encouraging maintenance signal the project has produced, and it lowers (but does not eliminate) the expected cost of the next one. The bad news is the corresponding obligation: this package now moves when Filament moves, so plugin upgrades land in the same window as your own Filament upgrade, exactly when the team is already busy. Assign a named owner in the Laravel team, add the package to the dependency-review list, and keep a short internal changelog noting every upstream diff you adopt. Budget the upgrade as part of the Filament upgrade project, not as a separate line item.

Support. Community-only, no SLA, no vendor to escalate to. Response time on issues is a function of one person's availability. For an internal admin reporting tool this is usually acceptable; it becomes unacceptable if reports are customer-facing or tied to billing/compliance outputs. Decide which of those this is before adoption, because it changes the answer. Note also that reporting a v4 bug now puts you in a small pool of early users, which is good for getting attention and bad for the maturity of the code you're running.

Scaling. The scaling axis is query cost, not request volume — a handful of users can each trigger a table scan. Watch for: unindexed filter columns, GROUP BY over large fact tables, per-row relationship access in report renderers (N+1), and exports buffered in memory. Mitigations are ordinary Laravel ones — composite indexes matched to default filters, materialized/rollup tables or nightly aggregates for the heavy reports, queued exports with signed download links, caching of expensive aggregates with explicit invalidation. None require the package to cooperate, which is reassuring: the escape hatch is a plain Filament page with the same query. Treat the escape hatch as the scaling plan's foundation — it is also the migration plan if upstream stalls.

Failure modes.

• Filament ships the next major and the plugin lags; reports page 500s or renders blank until forked and patched. 4.0.0 shows the maintainer can do this, not that they will do it on the next one.
• The 3.x line quietly stops receiving fixes, stranding teams that adopt now and defer their Filament v4 upgrade.
• Plugin 4.0.0 on Filament v4 exhibits fresh-release defects: asset/Tailwind drift, Livewire lifecycle changes in widget refresh, or Filament v4 schema API changes affecting filter forms — bugs with no issue-tracker precedent to search.
• Silent tenancy regression across the v3→v4 boundary: if the plugin's query path doesn't honor Filament's tenancy scoping on the new API, users see cross-tenant aggregates — the highest-severity failure here and the one to test explicitly.
• Synchronous export on a large range exhausts memory or trips max_execution_time, presenting to users as a silent failure or a 504.
• Date/timezone boundary drift between PHP and the database produces off-by-one report totals, which erodes trust faster than an outage.
• Asset regression after a Filament theme change produces an unstyled but "working" page that nobody files a bug about.
• Upstream abandonment: no security patch path except the fork.

Ramp-up. Low for anyone already fluent in Filament — the mental model (panel, page, widget, form schema for filters) transfers directly, and a developer should be productive in half a day to two days. If the team is simultaneously learning Filament v4, add that on top; the plugin does not teach you the new panel APIs. The non-obvious ramp-up cost is domain-side, not package-side: whoever writes reports needs to understand the underlying data model well enough to know which joins fan out and which aggregates double-count. Budget that separately; it dwarfs the framework learning curve and is the actual determinant of whether the reports are trusted.