Voyager Export Laravel Package

Product Decisions This Supports

• Feature scoping for the admin panel: Export-to-CSV/Excel is table-stakes functionality for internal ops tooling. This package lets you ship it as a configuration task instead of a sprint, which frees roadmap capacity for differentiating work.
• Build vs. buy (vs. vendor): The surface area here is small — an export action layered onto Voyager's BREAD listings. A PM should frame this as "borrow, don't bet on it": the MIT license and thin footprint mean you can vendor/fork the code if upstream goes quiet, rather than treating it as a strategic dependency.
• Admin stack strategy: Choosing this package is implicitly a vote to stay on Voyager. That is the real decision — not "do we add export buttons," but "are we continuing to invest in a Voyager-based admin, or is this the moment to evaluate Filament/Nova and treat Voyager as legacy?"
• Use cases it unlocks: Ad-hoc data pulls for finance and ops, support teams needing customer records without engineering tickets, compliance/reporting extracts, and spreadsheet-based reconciliation workflows.
• Data governance decisions: Any export path is an exfiltration path. This package forces an explicit conversation about who can export, what gets logged, and which tables are off-limits — decisions that are cheaper to make now than after an incident.
• Migration sequencing: With zero dependents and a single maintainer-adjacent release in early 2024, treating this as a candidate to replace with native framework tooling (Laravel Excel, Filament export actions) at the next admin refresh is a reasonable roadmap line item.

When to Consider This Package

Adopt when:

• You are already running Voyager and the admin is internal-facing with a low compliance bar.
• You need basic, on-demand exports of BREAD-managed tables and want them this week, not this quarter.
• Your team's engineering time is better spent elsewhere; the alternative is a few days of wiring maatwebsite/excel plus permission plumbing.
• You are comfortable pinning a version and reviewing the source before shipping — the codebase is small enough to audit in an afternoon.

Look elsewhere when:

• You are not on Voyager, or you are on a Laravel/PHP version the package has not been validated against. The February 2024 release predates current framework lines; verify compatibility before committing.
• You need scheduled/recurring exports, streaming for large tables, chunked jobs, or delivery to S3/email — this is an on-demand UI action, not an ETL tool.
• You need row-level scoping, field-level redaction, or a full audit trail on exports. Assume you must build these around it.
• You need vendor support or a community to lean on: 7 stars and 0 dependents means no Stack Overflow answers, no third-party bug reports, and no signal that breakage will be noticed by anyone but you.
• Exports touch PII, financial records, or anything regulator-visible — in that case, buy a maintained solution or build with explicit controls.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, MIT-licensed add-on that gives our internal admin panel spreadsheet export in days rather than weeks. It is a tactical accelerator, not a strategic platform bet — the code is small enough that we can absorb it in-house if the maintainer stops shipping. Recommend a scoped pilot in the internal admin, with a permission gate and export logging, and a review at the next admin-platform decision point. We should not extend it to customer-facing or regulated data without hardening.

To engineering: Thin module over Voyager BREAD that adds export actions to listings. Small, readable surface — plan to fork and vendor it rather than depend on upstream releases. Before rollout, audit three things: authorization (does the export honor the same row-level scoping as the list view, or does it dump the whole table?), memory behavior on large tables, and whether export events are logged with actor, table, and row count. Wrap it behind a dedicated permission and an audit hook; budget roughly a day for that hardening. Flag any Laravel/PHP version gap between the Feb 2024 release and our runtime as the primary integration risk.