Filament Action Export Laravel Package

Technical Evaluation

Architecture fit. The package is Filament-native rather than framework-adjacent: it ships two action classes (FilamentExportBulkAction, FilamentExportHeaderAction) that drop into ->bulkActions([]) / ->headerActions([]) and a shared InteractsWithExportAction trait (extracted in 3.7.0) that single-sources config defaults. Since 3.1.0 the panel plugin was removed, so there is no service-provider registration decision to make — integration is pure resource configuration, which matches how our panels are already assembled. The fluent API (->formats(), ->excludeColumns(), ->modifyQueryUsing()) reads like first-party Filament, so it is legible to any dev who knows the framework. Underlying dependencies are mainstream (Spatie SimpleExcelWriter for CSV/XLSX, barryvdh/laravel-dompdf with optional Snappy for PDF), all MIT/BSD and already common in Laravel estates. No migrations, no new tables, no external services.

Integration feasibility. One composer require, optional publish of config/views/translations, and a handful of lines per table. First working export is a 1–3 dev-day effort; a vetted internal wrapper plus authorization/audit work is 3–5 days. Exit cost is low: the public surface is small and the heavy lifting sits in libraries we could call directly.

Technical risk. Ranked by what would actually page someone:

Key questions to resolve before adoption.

1. Which Filament major are we actually on, and does that pin us to a maintained branch?
2. Does the bulk action enforce policies per selected record, and does the header action respect any global scope we rely on for tenancy?
3. What is the row-count ceiling for in-request generation on our PHP-FPM pool, and who owns the queue-based fallback?
4. Are generated files written to disk transiently? If so, where, who cleans them, and are they guessable URLs?
5. Can we get an audit trail (who exported what, how many rows, which filters) — in-package or bolted on?
6. Is extraViewData() escaped in the PDF/print Blade templates, or do we own that risk?
7. Is the 2026-09-24 "last release" timestamp real, or a metadata artefact? Verify against Packagist before we cite project health.
8. Does the maintainer respond to issues with a plausible cadence, and will they accept a security patch PR? Test with a low-stakes PR.

Integration Approach

Stack fit. Declared requirements: PHP ^8.2, Laravel ^11, Filament ^5, Livewire ^4. We must confirm against composer.lock, not the README — a Filament 4 estate means v2.x and a different risk conversation. Nine bundled locales (en, pt_BR, es, fr, de, it, nl, ar, tr) cover most of our admin surface; anything outside that list is a publish-and-translate task.

Migration path. Two scenarios: (a) greenfield — add actions to the resources that need export and move on; (b) replacing an existing exporter such as pxlrbt/filament-excel — do not run both on the same table, pick one per resource and migrate table-by-table so users see one export button, not two. There is no data migration; the only state is configuration. The exit ramp is cheap because we will wrap it (below), so a future swap is a single class rewrite rather than a codebase sweep.

Compatibility and contract discipline.

• Pin the exact minor in composer.json ("^3.7" at most), never a floating constraint.
• Treat the fluent API as a vendor API: our wrapper is the only place allowed to call it.
• Do not publish views or config unless genuinely required; if we publish the PDF/print/preview Blade templates, we own a fork that must be re-diffed every release.
• Validate the default_format and pdf_driver env keys in staging — config drift here is a classic "works on my machine" export break.

Sequencing.

1. Spike (2–3 days). Wire both actions onto a low-sensitivity internal resource with ~2k rows. Exercise CSV, XLSX, PDF; test preview, print, direct download, column exclusion, additional columns, and modifyQueryUsing. Confirm withFilters()/withSearch()/withSort() actually produce filtered output — assert on row counts.
2. Code review + security review (2 days). The package is small enough to read in an afternoon: two action classes, one trait, three Blade templates. Focus on query construction, escaping in templates, temp-file handling, and whether policy checks precede export.
3. Internal wrapper (2 days). App\Support\Exports\TableExportAction exposing only the options we have vetted, with our defaults (locale, delimiter, orientation, filename convention, excludeColumns for known-sensitive fields). This is the single highest-leverage step for a TPM: it converts a third-party dependency into an internal contract.
4. Authorization and audit (2–3 days). Gate both actions behind a dedicated export ability, mirror tenant global scopes to be safe, log (user, resource, filters, row_count, format, timestamp).
5. Rollout. Internal-admin resources first, then customer-facing or tenanted resources only after two sprints of clean logs.
6. Go/No-Go gate. Adopt broadly only if: no security findings in step 2, maintainer has responded to at least one issue within ~14 days, and the pinned version has survived a full Filament upgrade cycle without our fork.

Operational Impact

Maintenance. Budget roughly half a day per month: dependency bumps (Renovate/Dependabot with manual review, not auto-merge), one changelog read per release, and a re-run of the export smoke tests. Because the project iterates quickly as a solo effort, we should maintain a private fork or vendor patch capability from day one — cheap now, expensive during an incident. If any views are published, add a release checklist item to diff upstream templates.

Support. There is no commercial support and effectively no community support at 8 stars / 0 dependents. Our SLA is our own engineering capacity. That means: a named internal owner, a runbook covering "export produces empty file," "PDF 500s," "filters ignored," and "download times out," plus a documented decision to fork if issue response goes cold for >30 days. Legal review is trivial (MIT), but the maintainer concentration should be logged as an accepted dependency risk.

Scaling. Establish hard thresholds rather than discovering them in production:

• Under ~5k rows: synchronous in-request export is fine.
• 5k–50k rows: isolate the export request from the main pool (separate worker/queue or a dedicated PHP-FPM pool) with explicit memory_limit and max_execution_time.
• Above ~50k rows, or any PDF: move off-request. The package does not document a queued path, so plan a queue job that builds the file and serves it via a signed, expiring URL — this is our build, not theirs, and should be scoped as such.
• Concurrency: PDF generation is an order of magnitude heavier than CSV. Cap concurrent PDF exports per user and globally; two careless clicks on a 20k-row PDF can starve an admin panel.
• Storage: if we persist files, define retention (hours, not days) and lifecycle cleanup.

Failure modes to instrument and alert on. Request timeout / OOM on large exports; empty print or empty PDF output (an observed defect class upstream — v3.6.9 fixed state-path resolution); silently unfiltered datasets (the highest-severity failure); missing wkhtmltopdf binary when Snappy is enabled; DomPDF remote-asset fetch stalls; filename collisions under concurrent exports; unescaped extraViewData injection into PDF templates; PII leaving the system with no audit record. Alert on export error rate, p95 export duration by row count, and export volume per user — an anomalous spike in the last metric is a data-exfiltration signal, not a UX metric.

Ramp-up. A senior Laravel dev is productive in half a day; two of the options (writer callbacks, modifyQueryUsing stacking) warrant a short internal note. Knowledge will concentrate in one or two people, so the wrapper plus runbook is the mitigation. Realistic team ramp: one week to confident usage across the squad.

TPM recommendation. Conditional adopt, scoped and wrapped: ship it to internal admin tables within one sprint behind a policy, keep it out of customer-facing and multi-tenant surfaces until the security review and audit logging are in place, pin the version, and hold a fork-ready posture. The integration cost is low enough that the main risk is not engineering effort — it is trusting an unvetted single-maintainer package with our data egress path.