Nova Queued Export As Csv Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-panel exports. This package is a narrow, MIT-licensed Nova Action rather than a platform. The real decision it informs is whether ad-hoc CSV export from Nova resource tables is worth any custom engineering at all — if the answer is "no," adopt this and move on; if exports are becoming a customer-facing or revenue-reporting surface, that's a signal to invest in a first-party data pipeline instead.
• Roadmap prioritization for internal tooling. Queued export is the difference between support/finance/sales-ops being able to pull their own lists and those requests becoming engineering tickets. That has a measurable ROI (tickets avoided, turnaround time) and belongs on the internal-tooling roadmap, not the product feature roadmap.
• Supporting large datasets without bespoke jobs. Because export runs through the queue, it lets you defer a "proper" export service while still handling results too large for a synchronous request — a useful stopgap decision when you need to unblock ops this quarter, not next.
• Feature scoping for data access. It clarifies a boundary: CSV-for-humans-from-the-admin-panel is a solved, commodity need; anything requiring scheduled delivery, column selection, PII redaction, or audit trails is explicitly not covered and must be scoped separately.
• Risk tolerance for third-party dependencies. With 21 stars and zero dependents, this is a utility to be evaluated and possibly vendored, not a strategic dependency. That itself is a decision worth recording.

When to Consider This Package

Adopt (or vendor) when:

• You already run Laravel Nova — this is a hard prerequisite; it is an Action, not a general exporter.
• The need is internal, ad-hoc, human-initiated export from Nova resource index views.
• Datasets are large enough that a synchronous export risks request timeouts, and you already operate queue workers.
• CSV fidelity is sufficient — no formatting, formulas, or multi-sheet requirements.
• Engineering time is the constraint and a fork-on-abandonment posture is acceptable for a small, readable action.

Look elsewhere when:

• You need scheduled/recurring exports, delivery to email/S3/SFTP, or warehouse sync — that is a different product (BI/ELT, not an admin action).
• Compliance requirements demand auditable, permission-scoped, or PII-redacted exports; this package is not a governance layer.
• You need XLSX/Parquet, custom column selection, or streaming at millions of rows.
• You are not on Nova, or you are evaluating Nova itself — in which case the export capability should be one line item in a Nova vs. Filament vs. build-your-own comparison, not the deciding factor.
• Maintenance guarantees matter: single-maintainer, low-adoption projects carry bus-factor risk that must be priced in.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed add-on that turns a recurring "can someone pull this list for me?" request into self-service inside the admin panel. It costs effectively nothing beyond a short integration and a queue worker you likely already run. The strategic value is optionality: it defers any investment in a real reporting/export platform until demand is proven. The risk is equally bounded — it lives inside the admin panel, touches no customer-facing surface, and is small enough to fork if abandoned.

To engineering: A single Nova Action that dispatches an export to the queue and produces a CSV, using the queue and filesystem abstractions already in the stack. No schema changes, no new infrastructure. Caveats to validate before rollout: queue worker memory ceilings on very large resource sets, where generated files land and how they're expired (a storage-hygiene and PII-retention concern), and the fact that the export respects the action's authorization but not necessarily row-level policy you may have layered on elsewhere. Given 21 stars and zero dependents, treat it as vendored code — read it, pin it, and be prepared to own it. Recommended posture: pilot on one or two internal resources, measure ticket reduction, then decide whether to standardize or replace with a first-party path.