Statamic Fallow Laravel Package

Technical Evaluation

Architecture fit Fallow is a Laravel/PHP package that integrates with Statamic and, per the release notes, depends on Statamic internals rather than its public API surface. That is the single most important architectural fact available: it means Fallow sits below the supported extension boundary of the host CMS. For a Laravel shop already standardized on Statamic this is acceptable-but-conditional; for a shop running Statamic only incidentally, or one that pins Statamic loosely, it is a coupling that the platform owner does not contract to preserve.

Integration feasibility Feasible but unproven at this stage. We have no prior assessment, no dependency manifest, no PHP/Laravel version constraints, and no test or CI evidence in the supplied data. What v0.1.2 does tell us is that the package is installable and being distributed as a normal Composer artifact with an export-ignore build — a real distribution pipeline exists, and this release corrects a packaging defect in it.

Technical risk

• Version maturity (high): v0.1.x signals pre-stable API. Expect breaking changes on minor bumps; do not consume with a caret constraint beyond patch.
• Internal coupling (high, structural): Reliance on Statamic internals means a Statamic minor upgrade can break Fallow with no deprecation cycle. The maintainer's own documentation of this coupling lives in the repository, not the installed package — meaning the operator running composer update cannot read the compatibility caveats from vendor/. This is a defensible hygiene decision, but it shifts burden onto us: we must track the repo, not the artifact.
• Release content (low): v0.1.2 changes no code. Removing NOTES.md from the dist has zero runtime effect. No migration, no deprecation, no behavior change.
• Process signal (moderate): Two consecutive patch releases (0.1.1, 0.1.2) have been packaging-hygiene fixes, one of which was an admitted miss ("this one was missed"). Early build discipline is still settling. Not alarming at 0.1.x, but it argues against adopting before the packaging churn stops.

Key questions

1. Which Statamic internals does Fallow touch, and is that list version-pinned anywhere machine-readable (composer constraints, CI matrix) rather than prose?
2. What are the declared PHP / Laravel / Statamic version constraints, and is there a CI matrix exercising the supported Statamic range?
3. Is there a published compatibility policy for Statamic minor releases, or is breakage discovered by users?
4. What is the test coverage story, and does the suite exercise against real Statamic internals or stubs?
5. Roadmap to 1.0 — is API stabilization planned, and on what timeline?
6. Where is the repository-hosted NOTES.md discoverable from the package (README link, Packagist description)? If not, operators have no in-band pointer to the coupling documentation.

Integration Approach

Stack fit Assumes a Laravel application with Statamic installed and Fallow layered on top. Fit is good where the team already owns Statamic content modeling and is comfortable with the Laravel service-provider/config-publish idiom. Fit is poor where Statamic is one of several CMSs or where the team cannot commit to tracking Statamic upgrades deliberately.

Migration path Nothing to migrate for v0.1.2 — it is a packaging-only patch with no code delta. Adopters moving from 0.1.1 to 0.1.2 should see an identical runtime and one fewer file in vendor/. The only migration-shaped concern is the long-term one: because Fallow tracks Statamic internals, every future Statamic upgrade is effectively a Fallow migration event and should be scheduled as one.

Compatibility Unverified from the supplied data. The material compatibility risk is not Laravel or PHP — it is the Statamic version window. Treat the supported Statamic range as unknown until the constraints and CI matrix are reviewed. The removal of NOTES.md from the artifact marginally reduces our ability to confirm compatibility from an installed environment, so compatibility must be established from the repository before install.

Sequencing

1. Read the repository's NOTES.md and dependency constraints before any install; treat it as required pre-reading.
2. Pin Fallow exactly (0.1.2, no caret) and pin Statamic to a tested minor.
3. Trial in a non-production Statamic environment; exercise the Fallow-specific content paths, then run a Statamic patch upgrade in the same environment to observe coupling behavior.
4. Only after that, promote to production with an explicit Statamic-upgrade runbook entry.
5. Re-evaluate at 0.2.0 or at first 1.0 release candidate, whichever comes first.

Operational Impact

Maintenance Ongoing maintenance cost is dominated by Statamic upgrade tracking, not by Fallow itself. Budget for a compatibility check on every Statamic minor release, and for reading the upstream repository (not the vendored package) when doing so. The NOTES.md exclusion makes this a deliberate process step rather than something a developer stumbles across in vendor/.

Support At 0.1.x, expect maintainer-response-dependent support with no SLA and no LTS branch. No evidence in the supplied data of commercial backing, security policy, or a support channel. Plan for the team to own diagnosis; treat upstream as best-effort.

Scaling No scaling signal in this release. The relevant scale dimension for a Statamic addon is content volume and template/render path overhead, which needs a benchmark in a representative environment rather than inference from a packaging patch.

Failure modes

• Silent breakage on Statamic upgrade: the primary failure mode. Symptoms surface at render or save time, not at composer update time, because internals have no version contract. Mitigation: staging upgrade rehearsal plus a pinned Statamic minor.
• Misdiagnosis from missing documentation: an engineer debugging in a built environment will not find NOTES.md and may not know the coupling exists. Mitigation: record the repo link and coupling note in our own internal runbook, since upstream has removed the in-package copy.
• Version drift: a caret range pulling a 0.x minor with breaking changes. Mitigation: exact pins, deliberate bump reviews.
• Packaging regressions: two consecutive hygiene fixes suggest the build pipeline was recently adjusted; low severity, but verify artifact contents on upgrade rather than assuming.

Ramp-up Low for anyone fluent in Laravel and Statamic — installation and configuration follow familiar conventions. The non-obvious ramp-up is institutional: the team must learn which Statamic internals Fallow depends on and internalize the upgrade-check ritual. That knowledge now has to be sourced from the repository and captured internally, because v0.1.2 deliberately keeps it out of the installed package. Budget a short onboarding doc as part of adoption; without it, the coupling risk is invisible to everyone who did not read this review.

Verdict on v0.1.2: no functional change, no action required for existing installs, no change to the risk posture beyond a marginal documentation-visibility tradeoff. Assessment stands as an initial baseline; re-evaluate at 0.2.0 or on any release that touches code.