Statamic Entries Export Laravel Package

Technical Evaluation

Architecture fit. The package is a Laravel/PHP add-on whose compatibility surface now explicitly includes Statamic 5 (release 2.1.1, PR #8). That places it in the Statamic addon ecosystem rather than as a standalone Laravel library, which materially narrows the addressable use cases: it is only relevant to projects already running (or planning) Statamic as the content layer on top of Laravel. For those projects it is a low-friction fit; for Laravel-only applications it should be treated as out of scope until we confirm whether the Statamic dependency is optional or hard.

Integration feasibility. Adding Statamic 5 support is a positive signal — it means the maintainer is tracking the current major of the host framework rather than letting the package rot. Statamic 5 sits on Laravel 11 and PHP 8.2+, so this release effectively raises our platform floor. Feasibility is high for greenfield Statamic 5 builds; for existing Statamic 4 estates the question is whether a 2.1.x line still supports the older major or whether upgrading the package forces a Statamic upgrade.

Technical risk. The dominant risk is that we have essentially no primary data on this package in the current record — no repository metadata, no dependency manifest, no test coverage signals, no download or issue history. The assessment below is therefore inferred from release-note behaviour, not verified. Secondary risks:

• Single-maintainer / bus-factor exposure, evidenced by a single external contributor handling the Statamic 5 bump.
• Version-pinning fragility — if the Statamic constraint is a caret range on 5.x, minor Statamic releases could break us without a package release.
• Semantic-versioning ambiguity — 2.1.1 is a patch release that adds support for a new host major; that is arguably a feature (minor) or, for teams still on Statamic 4, a compatibility-affecting change. We should not assume patch-level safety.

Key questions.

1. Is Statamic a required or optional dependency? Can the package be consumed in a plain Laravel app?
2. What are the exact composer.json constraints for statamic/cms, laravel/framework, and php?
3. Does 2.1.1 drop Statamic 4 support, or is the constraint a disjunction (^4.0|^5.0)?
4. What is the test matrix — is there CI coverage against both Statamic majors and against the minimum PHP version?
5. Who is the maintainer of record, and what is the release cadence over the last 12 months?
6. What does the package actually do (the release notes describe compatibility work, not capability)?

Integration Approach

Stack fit. Target footprint is Laravel 11 / PHP 8.2+ / Statamic 5. Any service still on Laravel 10 or PHP 8.1 must either stay on an earlier package line or absorb a framework upgrade as part of adoption — that coupling is the single most important planning input and should be confirmed before we commit to a design.

Migration path. Two distinct paths:

• Greenfield Statamic 5 build — adopt 2.1.1 directly, pin exactly (2.1.1) rather than floating, and re-evaluate on each release.
• Existing Statamic 4 estate — sequence the package bump behind the Statamic major upgrade, never alongside it. Combining a host-framework major and an addon change in one release makes rollback and blame attribution much harder.

Compatibility. Establish a compatibility matrix as an explicit deliverable: package version × Statamic major × Laravel major × PHP minor. We cannot currently populate the Statamic 4 column. Treat Statamic 4 support as unknown, assumed present until disproven and verify against composer.json before any planning commitment. Also confirm whether the addon publishes config, migrations, or assets — if so, the upgrade path is not purely a Composer operation.

Sequencing.

1. Retrieve and review composer.json, README, and CI configuration (unblocks everything else).
2. Spike: install 2.1.1 in a throwaway Statamic 5 project; capture install size, published files, and any service-provider side effects.
3. Confirm Statamic 4 behaviour — resolve the dependency in a 4.x project and record the result.
4. Run a two-week timeboxed pilot in a non-critical environment.
5. Decision gate: adopt, adopt-with-pin, or defer.
6. Only then open a production integration ticket.

Operational Impact

Maintenance. Low-to-moderate ongoing effort, contingent on the release cadence being modest. The Statamic 5 uplift landing in a patch suggests reactive rather than scheduled maintenance; we should budget for periodic "does this still install?" checks rather than assuming continuous readiness. Own the pin ourselves — do not rely on the maintainer for stability guarantees.

Support. Support is community-style: GitHub issues and PRs, with an external contributor responsible for the most recent compatibility work. There is no evident commercial backing. That is acceptable for non-critical content tooling and unacceptable for anything on a revenue-critical path without an internal fallback plan. Identify an internal owner who can read the source if upstream goes quiet.

Scaling. Nothing in the release notes indicates runtime performance characteristics. Scaling risk here is organisational, not technical: the constraint is how many of our applications we are willing to tie to a single-maintainer addon, not throughput. Keep blast radius small — adopt in one or two services first.

Failure modes.

• Silent breakage on host upgrade — a Statamic minor release changes behaviour the addon depends on; the caret constraint lets it through. Mitigation: exact pins plus a lockfile-review step in the upgrade runbook.
• Abandonment — no releases for an extended period while Statamic moves on. Mitigation: monitor release recency as a tracked health metric; pre-identify a fork-and-maintain option.
• Constraint conflict — the addon's Laravel or PHP constraint blocks an unrelated dependency upgrade. Mitigation: surface this in the spike, not in production.
• Transitive dependency surprise — the addon pulls in packages we have not vetted. Mitigation: review the resolved dependency tree during the spike.

Ramp-up. Low for developers already fluent in Statamic; effectively a new skill for Laravel-only engineers, since Statamic's content model and Antlers templating are the real learning curve, not this package. Budget roughly one sprint for a Statamic-fluent developer to reach productive use, plus review time from whoever validates the compatibility matrix. The blocking cost is not learning the addon — it is the framework upgrade required to reach it.