Voyager Export Laravel Package

Technical Evaluation

Architecture fit. joy/voyager-export is a plugin for Voyager, the Blade-based Laravel admin panel. It extends Voyager's existing BREAD (browse/read/edit/add/delete) listing screens with export actions rather than introducing a parallel admin surface. That means fit is binary: on a Voyager-backed admin it slots into the existing menu, ACL, and datatable conventions with little ceremony; on Filament, Nova, Inertia, or a custom admin it has no role. As a rule, the module is only worth evaluating if Voyager is already a committed part of the stack.

Integration feasibility. Straightforward in mechanics: composer require, service-provider auto-discovery, likely a published config, a Voyager menu entry, and role/permission assignment through Voyager's own ACL. Expect a spike measured in hours. The real cost is not installation but the transitive surface: the joy-voyager-* family (datatable/bread modules) plus a spreadsheet library (PhpSpreadsheet or maatwebsite/excel) will land in composer.lock and become constraints you carry forward.

Technical risk.

• Ecosystem ceiling. Voyager is in low-maintenance mode and its Laravel compatibility envelope is the binding constraint on the whole application. This package inherits that ceiling.
• Supply chain. 7 stars, 0 dependents, single maintainer, last release February 2024. By any reasonable standard this is effectively unmaintained; there will be no community triage and no security advisories. Treat it as source code you are adopting, not a dependency you are consuming.
• Permission surface. Export routes in admin modules frequently sit outside the BREAD ACL check. An export endpoint is a data-exfiltration endpoint; verify authorization explicitly before enabling it in production.
• Commodity value. An opportunity score of 21.01 and a sub-0.9 composite reflect a feature with little strategic leverage. Export-to-CSV is a 1–2 day build for a competent Laravel engineer; the package saves hours, not weeks, and the savings shrink once you add the fork, review, and ACL hardening you will need anyway.

Key questions.

1. Which Laravel and PHP versions are actually supported, and does that intersection include our target version?
2. Which joy-voyager-* and spreadsheet packages are hard dependencies, and what are their maintenance states?
3. Does the package enforce Voyager BREAD permissions on the export route, or only on the button?
4. What are the supported formats (CSV, XLSX), and is export synchronous or queueable?
5. How does it behave past ~10k rows — streaming, chunking, or in-memory?
6. Are there tests, a changelog, and a security contact? What is the commit cadence beyond the tagged release?
7. Is the export column set derived from the BREAD config, and how does it react to schema drift?

Integration Approach

Stack fit. Assumes PHP 8.x, a Laravel version within Voyager's supported window, and Voyager 1.6+. Database-agnostic, since export is driven by the BREAD query layer. Confirm the package's composer.json constraints before committing — a narrow Laravel range is the most likely blocker.

Migration path. Export is a shallow feature with a thin seam: one route, one button, one serialization concern. That makes lock-in low. If the admin is later rebuilt on Filament or a custom panel, the export capability is reimplemented against the same domain queries in a day or two. Do not let the package's data-shaping logic leak into controllers or models; keep it behind an internal ExportService contract so the swap is mechanical.

Compatibility. Pin exact versions in composer.json and commit the lock file. Add a CI smoke test that exercises one export end to end so Laravel upgrades fail loudly rather than silently at runtime. Where the package's constraints and the application's diverge, resolve with a fork rather than by holding the framework back.

Sequencing.

1. Sandbox spike against a single non-sensitive BREAD resource.
2. Wrap the package behind an internal interface and gate it with a feature flag.
3. Add an explicit authorization check (policy or Voyager permission) on the export route — do not rely on UI-level gating.
4. Move large exports to a queued job with streamed CSV output.
5. Roll out per-BREAD, starting with low-cardinality tables.
6. Set a decision gate: on the first upstream break, fork to a private VCS or replace with in-house code.

Operational Impact

Maintenance. Budget for ownership, not consumption. Assume you will vendor or fork the package. There is no release cadence to depend on, no deprecation policy, and no security disclosure channel — you are the maintainer of record for any security defect found in it.

Support and ramp-up. No documentation community, no issue triage. Onboarding cost is modest: a Laravel developer needs roughly one to two days to learn Voyager's BREAD, ACL, and menu conventions, and the package's own code surface is small enough to read in full. That readability is the main mitigant to the abandonment risk.

Scaling. Synchronous spreadsheet generation is memory-bound and will exhaust limits in the tens of thousands of rows, particularly on shared or containerized hosting with low memory_limit. Push exports to a queue, stream CSV rather than materializing a workbook, cap concurrent exports, and rate-limit the route. Export is also a database-load amplifier — a full-table export runs the same query as the listing screen without pagination.

Failure modes.

• Memory exhaustion or request timeout on large exports, surfacing to users as a blank page rather than an error.
• Authorization bypass if the route is not gated by the BREAD ACL.
• CSV formula injection (=, +, -, @ prefixes) if exported cells are opened in Excel.
• Column drift when BREAD configuration changes, producing silently wrong or missing fields.
• Silent breakage after a Laravel or Voyager upgrade, with no upstream fix forthcoming.
• No progress feedback for long-running synchronous exports, leading to duplicate submissions.

Recommendation. Conditional adoption. Use it only where Voyager is already committed, pin and fork it from day one, gate the route with explicit authorization, and queue anything beyond pilot volumes. Absent an existing Voyager investment, build the export in-house — the package's low adoption, single maintainer, and commodity scope make it a liability that does not repay the diligence it requires.