Statamic Export Laravel Package

Technical Evaluation

Architecture fit doefom/statamic-export is a Statamic addon, not a general-purpose Laravel package — its value is entirely contingent on Statamic being the content layer of the application. It slots into the Statamic control panel as an export action against collections/entries and relies on Statamic's service-provider registration and permission/action APIs. For a Statamic-backed Laravel app this is a low-ceremony fit; for a plain Laravel app (Eloquent models, non-Statamic content), it is not usable and should be rejected at triage.

Integration feasibility Standard Composer install with addon auto-discovery, likely a publishable config, and a control-panel-facing surface that content editors can use without developer involvement. No infrastructure prerequisites beyond the Statamic runtime. The main feasibility question is version-matrix support (Statamic major, PHP minor) rather than integration effort.

Technical risk

• Pre-1.0 maturity. v0.8.x signals an API surface still in motion. Semver guarantees before 1.0 are weak; minor bumps can carry behavior changes.
• Single-maintainer risk. Release history is driven by one contributor (@doefom). Bus factor and long-term maintenance are the dominant risks, not code quality.
• Behavioral change in a patch release. v0.8.1 ("Normalize export cell values to strings", PR #24) alters the type of every exported cell. This is the kind of change that looks cosmetic but silently rewrites contracts with downstream consumers: spreadsheet formula evaluation, numeric/date parsing in BI tools, and ETL pipelines that infer schema from the first rows. Shipping that as a patch (not a minor) is a governance signal worth noting.
• Evidence base is thin. The assessment rests on a single changelog line and no inspection data; confidence should be treated as low until validated against a real export.

Key questions

1. Which Statamic and PHP versions are supported, and what is the tested matrix?
2. Did v0.8.1 change CSV escaping/quoting, null handling, date formatting, or BOM/encoding — or only in-memory typing?
3. What is the export format coverage (CSV only, or XLSX/JSON)?
4. Are large exports chunked/queued, or synchronous and memory-bound?
5. How are field types with nested structure (grids, relationships, assets) flattened?
6. Is there automated test coverage, and is there a security policy for reporting issues?
7. Who owns the package if the maintainer steps away — is a fork viable?

Integration Approach

Stack fit Requires a Laravel application running Statamic. The export surface is CP-facing, so integration is mostly configuration and permissions rather than application code. If the same export must also be triggered programmatically (scheduled reports, API endpoints), confirm the underlying export logic is callable outside the CP action — this is not guaranteed by an addon of this shape and is the most likely place to need custom glue code.

Migration path No database migrations or data-model changes are expected. The migration concern is downstream: v0.8.1 changes cell typing, so any already-generated export files or stored artifacts produced on v0.8.0 are no longer type-comparable to new ones. Treat the export schema as a versioned interface — if exports feed a warehouse, reporting layer, or client deliverables, plan to re-baseline those consumers alongside the upgrade.

Compatibility Pin the version exactly (0.8.1) rather than floating a caret constraint. Pre-1.0 constraints resolve loosely and a future 0.9 may change behavior again. Explicitly verify PHP and Statamic constraints against the host app before installing, and re-verify on every Statamic minor upgrade — addons commonly lag the CMS.

Sequencing

1. Install in a non-production Statamic environment with representative content, including edge cases (empty fields, multi-value fields, non-ASCII text, large collections).
2. Capture a golden-file fixture of exports pre- and post-upgrade. Given the v0.8.1 typing change, this regression harness is the single highest-value control and should be a prerequisite to production rollout, not a follow-up.
3. Validate the output in the actual downstream consumer (Excel, BI tool, ingestion job) — not just by eyeballing the CSV.
4. Confirm permissions and audit expectations with the content/ops owners.
5. Roll to production behind an exact version pin.

Operational Impact

Maintenance Low ongoing effort for the integrating team under normal conditions, but the package itself carries concentrated maintainer risk. Mitigation: keep the version pinned, vendor/fork the repository internally, and be prepared to carry patches. Because the package is small and single-purpose, a fork is realistically maintainable — that is the primary reason the risk is tolerable.

Support Community-only support via GitHub issues, no SLA, no commercial backing identified. Escalation paths are effectively "fix it ourselves." Budget for that expectation up front rather than discovering it during an incident.

Scaling The open question is export execution model. Synchronous export of large collections will hit PHP memory limits and request timeouts; the failure is not graceful. If the use case involves anything beyond modest collections, validate throughput and memory behavior during the sandbox phase and plan for chunking, queueing, or a custom export job. This is the most likely source of post-launch operational surprise.

Failure modes

• Silent type coercion (directly implicated by v0.8.1): numbers and dates arriving as strings and being misread downstream — wrong sort order, broken formulas, rejected rows. Fails quietly, not loudly.
• Truncated or partial exports on timeout/memory exhaustion, presenting as complete files.
• Encoding/escaping corruption with non-ASCII content or embedded delimiters.
• Permission leakage if export actions are exposed more broadly than intended.
• Upgrade breakage when a future 0.9.x lands against a newer Statamic.

Ramp-up Near-zero for Laravel developers familiar with Statamic — install, configure, expose to editors. Content editors need only a short walkthrough of the export action and expected column layout. The real ramp-up cost sits with the consuming team, who must understand that export cell types are a contract that the package can change in a patch release.