Exporter Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the export capability. Export of entities, reports, and admin data is recurring, low-differentiation work. This package is valuable as a specification of the problem — a registry of named exporters, pluggable format writers, and configurable export definitions — not as a component to ship. It helps the team write a sharper v0 ticket for an internal ExportService rather than rediscovering scope per feature.
• Roadmap scoping for back-office and reporting tooling. The use cases it maps to are concrete and near-term: CSV/XLS admin exports, finance and ops reporting extracts, GDPR/customer data pulls, and bulk tooling. Treating export as one first-class capability instead of a per-screen reinvention is a roadmap simplification with a small, predictable cost.
• Stack and framework-fit gate. The package is a Symfony 2 bundle; Symfony 2 reached end-of-life in 2018, and bundles do not port into Laravel's service-provider and container model. This is a clear "framework fit = no" data point that justifies defaulting to Laravel-native libraries rather than evaluating PHP export packages generically.
• Dependency hygiene and supply-chain stance. 2 stars, 0 dependents, no release cadence, no ecosystem: that is a maintenance-liability signal, not an opportunity signal. PMs should use this as a standing example for dependency review — popularity and opportunity scores measure need in the market, not safety of the artifact.
• Risk posture for customer-facing vs. internal exports. Internal tooling tolerates some rough edges; compliance or customer-facing export does not. This assessment clarifies that anything correctness-critical should sit on maintained libraries with an upgrade path.

When to Consider This Package

Adopt only if all of the following hold:

• You are maintaining a legacy Symfony 2.x application that is frozen (no upgrade planned) and you need an exporter with minimal new code.
• You accept vendor lock to an unmaintained bundle — no security patches, no PHP 8 support, no community fixes — and have a plan for patching it internally.
• The export scope is genuinely trivial and small enough to hold in-house if the package breaks.
• There is a named owner who will absorb the fork permanently.

Look elsewhere — the likely outcome — when:

• You are on Laravel (any version) or Symfony 5/6/7. Use maatwebsite/excel, league/csv, or openspout directly; for Symfony, SonataExporter or a thin custom exporter.
• You need maintained dependencies, PHP 8+ compatibility, queueing, chunked/streaming exports, or format coverage beyond basic tabular output.
• You need prior art or hiring signal — 0 dependents and 2 stars means no production validation, no Stack Overflow corpus, and no external support to triage against.
• The export is customer-facing or compliance-relevant, where correctness and long-term support matter more than initial implementation speed.

How to Pitch It (Stakeholders)

Recommendation: do not adopt as a dependency. Use it as a design reference and build a thin, Laravel-native export layer in-house.

We evaluated idci/exporter-bundle as a shortcut for our data-export needs. It is a Symfony 2 bundle — a framework version end-of-lifed in 2018 — which makes it incompatible with our Laravel stack and unsupportable on modern PHP. Its adoption signal is weak across every dimension that matters: 2 GitHub stars, zero dependent projects, no release cadence, and no test evidence. The underlying need it addresses — configurable, format-pluggable export of entities and reports — is real and recurring, which is why the market opportunity score is high. But that score measures demand for the capability, not quality of this artifact.

Proposed path: one to two engineering days to implement a small ExportService with CSV and XLSX writers behind a common interface, bound in a service provider, wired to our existing auth and queue, and streaming downloads through Laravel's response layer. This gives us a maintained, testable, framework-native capability with no third-party lifecycle risk.

What we avoid: pulling a dead framework dependency into the codebase, inheriting an unsupported Symfony coupling we would have to rewrite anyway, and taking on a permanent maintenance line item we cannot escalate to a vendor.

What we keep: the package's design intent — a named-exporter registry plus pluggable writers — as the reference model for the ticket. Engineering should treat export as an internal utility, not a procurement decision, and should sequence the work as a small owned capability rather than a build-vs-buy evaluation.