Advanced Table Export For Filament Laravel Package

Product Decisions This Supports

• Build vs. buy on table export. Multi-format export (CSV, XLSX, PDF, DOCX, JSON, XML, clipboard) is a recurring ask from ops, finance, and support users, but it is rarely differentiating. This package lets you ship it in days rather than a sprint, freeing engineering capacity for core roadmap work.
• Filament v4/v5 upgrade decision. The incumbent (alperenersoy/filament-export) is the practical blocker for teams modernizing their admin panel. If your roadmap includes a Filament upgrade, this package is part of that migration scope, not a separate initiative.
• Self-serve column selection vs. engineering-built reports. v1.2.0 adds an end-user "additional columns" UI in the export modal (title + default value, KeyValue-based, with per-field label overrides and a disableAdditionalColumns() switch). That shifts a class of requests — "can the export include this derived field / this label instead" — from engineering tickets into user configuration. This is the difference between an export button and a lightweight reporting surface, and it directly affects how much you budget for ad-hoc reporting support.
• Feature scoping for reporting workflows. Column selection, preview-before-export, flexible PDF drivers, and now user-definable additional columns map directly to user stories like "let me pull only the columns I need into Excel" and "give me a printable PDF for a client meeting." These are cheap wins that reduce ad-hoc data requests to engineering.
• White-labeling / embedded-admin decisions. The new config key (disable_additional_columns) plus label helpers mean you can rebrand and constrain the export UI without forking. If you ship the admin panel to customers, this weakens the previous "you'll be forking" objection — but only for surface-level customization.
• Deprecating internal export scripts. Teams often maintain bespoke CSV/PDF endpoints or one-off Artisan commands. This package is a candidate to consolidate that surface area and shrink custom code you own.
• Buying signal for BI investment. If export usage is heavy and recurring (weekly board packs, scheduled finance extracts), that's evidence users want scheduled/recurring reporting — a prompt to evaluate a real reporting layer rather than doubling down on manual exports. Note the additional-columns feature deliberately lowers the pressure to buy BI for simple cases; watch whether it deflects or delays that evaluation.
• Compliance and data portability use cases. JSON/XML export supports data-access and portability requests without a bespoke pipeline, which can shorten responses to DSAR-style tickets.

When to Consider This Package

Adopt when all of the following hold:

• You are on Filament v4 or v5 (Laravel 11–13) and table export is a known gap.
• You need more than CSV — PDF/DOCX/print outputs are part of the actual user requirement.
• Your team accepts MIT-licensed, community-maintained dependencies with a single maintainer.
• Datasets are interactive/admin-scale (thousands of rows), not multi-million-row bulk extracts.
• Users are internal staff or trusted operators, i.e. export is a convenience, not a contractual SLA feature.
• New: You want end users to shape the export (add their own columns/labels) without an engineering ticket — or you explicitly want to switch that off via config.

Look elsewhere when:

• Procurement requires vendor support, an SLA, or security attestations. Five stars and zero dependents will not survive a vendor-risk review on its own.
• You need large-scale or queued exports. Streaming, chunked, background-job exports with download notifications are a different product; verify before committing.
• You need scheduled/recurring delivery (e.g. nightly XLSX to an S3 bucket or email). That is a reporting service concern.
• You are on Filament v3 and the existing filament-export still works. Migration cost with no user-visible gain.
• You already run a BI tool (Metabase, Looker, Power BI). Exporting from the admin panel may duplicate a solved problem and fragment the "source of truth" conversation.
• Heavy white-labeling or custom output formatting is required. v1.2.0 covers labels and field visibility, but deeper output-format control (templated PDFs, branded XLSX styling) still means forking — and then you own it regardless of license.

Mitigation to plan for on adoption: pin the version, wrap the export actions behind your own thin adapter/service class, and add integration tests around the formats you actually expose. Keep the additional-columns behaviour behind a config flag so a future swap (or fork) is a contained change rather than a rewrite.

How to Pitch It (Stakeholders)

To executives: Table export is a small, high-visibility quality-of-life feature that our admin users keep asking for. This package delivers it — CSV, Excel, PDF, Word, JSON, print — as a drop-in Laravel component under an MIT license, at effectively zero license cost and a fraction of the engineering time to build it. It is also the piece that unblocks our Filament v4/v5 upgrade, since the well-known predecessor package has not kept pace. The latest release lets users add their own columns to an export themselves, which converts a recurring stream of small engineering requests into self-serve configuration.

To engineering: Laravel/Filament-native, actively released (v1.2.0 shipped new end-user functionality and, notably, fixed a config key that was documented but never wired — a good sign someone is actually reading their own docs), MIT, and explicitly positioned as the maintained successor to filament-export. It handles the format plumbing (including PDF driver flexibility) that we would otherwise hand-roll, and it lives inside the Filament table layer where our existing actions already are. The new additional-columns UI is a KeyValue component behind disableAdditionalColumns() with field-label helpers, so it's configurable rather than baked in.

Disclose the risk plainly: adoption is still very early — a handful of stars, no dependents, effectively a single maintainer. The v1.2.0 additions increase surface area we'd depend on (modal UI behaviour, not just format plumbing), so scope the pilot accordingly. Treat it as a low-blast-radius dependency: contain it behind our own interface, pin the version, leave additional-columns disabled until we've validated it, and test the formats we surface. If it stalls, we fork or replace it in days, not quarters. Recommended ask: approve a time-boxed pilot on one internal admin table, with a go/no-go review after the first real usage cycle.