Statamic Peak Tools Laravel Package

Technical Evaluation

Architecture fit studio1902/statamic-peak-tools is not a general-purpose Laravel library — it is a companion package to the Statamic Peak starter kit, delivering shared Antlers partials/tools that Peak's own templates consume. Its architectural boundary is the Antlers rendering layer inside a Statamic site, not the application/service layer. It therefore fits cleanly only if we have already standardized on Laravel + Statamic + Antlers; on a Blade/Livewire-first Laravel codebase, or one moving toward Statamic's Blade/Element API direction, it adds a second templating idiom for marginal benefit. The "shared" in the description means shared within the Peak kit, which is an important scoping caveat: the partials likely assume Peak's blueprint/fieldset naming conventions and will not drop into an arbitrary Statamic site unmodified.

Integration feasibility Mechanically trivial: it is a Composer package registered via a Statamic addon service provider, so composer require plus an autoload is the whole integration. The real feasibility question is dependency resolution — we need to confirm the package's statamic/cms and laravel/framework constraints against our pinned versions before committing. Because the package is an internal detail of Peak, the honest framing for the product decision is: we are not evaluating this package, we are evaluating Peak. If Peak is adopted, this arrives as a transitive dependency and should be treated as such (pinned, not directly depended on). If Peak is not adopted, there is no compelling standalone use case for 11 stars' worth of partials.

Technical risk

• Licensing (highest severity): GPL-3.0 is copyleft and viral. For a single internal/agency-owned site that is never distributed, this is generally tolerable, but for any deliverable we ship to clients, resell, or package as a product, GPL-3.0 obligations may attach to derivative template work. This alone warrants legal review before adoption, and it is materially harder to unwind post-build than to flag now.
• Bus factor: effectively a single-studio project with a negligible community footprint. No independent maintainer bench, no evidence of external contribution, no security response process.
• Version/provenance anomaly: the listed last release date (2026-10-15) is in the future relative to normal release cadence, which suggests either metadata noise in the source registry or a date-handling artifact. Treat release metadata as unverified until checked against Packagist/GitHub directly.
• Antlers churn: Statamic has been steadily de-emphasizing Antlers in favor of Blade and the Element API. A package whose entire value proposition is Antlers tooling carries directional risk against the platform roadmap.

Key questions

1. Which Statamic major versions and PHP versions are supported, and what are the exact Composer constraints?
2. Are the Antlers tools usable outside Peak, or do they hard-depend on Peak's fieldsets/blueprints?
3. Do we have a written position on GPL-3.0 for client-delivered work, and has legal signed off?
4. Is there a maintained changelog and a stated deprecation/support policy?
5. What is the fallback if the maintainer stops publishing — how many partials would we actually need to reimplement?

Integration Approach

Stack fit Target shape: Laravel 10/11 + Statamic 4/5 + PHP 8.1+, Antlers templating, Composer-driven deployment. If our stack deviates on any of those axes — particularly if we are not on Statamic at all — this package should be rejected at triage rather than spiked. Fit is binary here, not gradual.

Migration path Three viable paths, in descending order of preference:

1. Adopt Peak (preferred if we're doing Statamic greenfield). Pull in studio1902/statamic-peak as the starter kit; statamic-peak-tools arrives as a transitive dependency. We never reference it directly, we pin the parent, and upgrades flow through Peak's release cadence.
2. Vendor selected partials. If we only want two or three specific Antlers tools on an existing Statamic site, copy those files into resources/views/ with attribution and a recorded GPL provenance note. This eliminates the dependency and the bus-factor risk, at the cost of manual sync — acceptable when the surface area is small. Confirm with legal that in-repo copying does not change the distribution analysis.
3. Direct composer require against a non-Peak site. Not recommended. We would absorb the full maintenance burden of a package designed for a context we do not occupy, with no upstream incentive to preserve our use case.

Compatibility Pin to an exact or tilde-constrained version and commit the lockfile. Do not float. Add a CI check that the resolved statamic/cms version satisfies both Peak's and this package's constraints after any Statamic upgrade — Antlers API changes between Statamic majors are the most likely breakage vector.

Sequencing

1. Confirm the platform decision (Statamic yes/no) — this gates everything else and should be a two-week timebox, not an open-ended spike.
2. If yes: legal review of GPL-3.0 against our delivery model. Do this before writing templates against it.
3. Install Peak in a throwaway branch; inventory which of these tools we would actually use and how many.
4. If the inventory is small (< ~5 partials), prefer path 2 (vendor) and drop the dependency.
5. If the inventory is large, adopt Peak wholesale (path 1) and record this package as a pinned transitive dependency.
6. Establish an upgrade ritual: Statamic minor → bump Peak → re-run template smoke tests.

Operational Impact

Maintenance Low code volume, non-trivial coordination cost. Maintenance is really upstream tracking: watching Peak's releases and Statamic's Antlers deprecations. Because we do not control the package, our maintenance burden is reactive rather than scheduled. Budget a recurring line item — roughly a half-day per Statamic minor upgrade — for template regression checks rather than for dependency patching.

Support Effectively none. There is no vendor, no SLA, no security disclosure channel we can rely on, and a community too small to substitute for one. Escalation path is a GitHub issue to a small studio with no obligation to respond. That is acceptable for a starter-kit partial set we could rewrite ourselves; it is not acceptable for anything on a critical rendering path we cannot afford to have break.

Scaling Not a concern. These are server-side template partials executed during Antlers rendering and fully compatible with Statamic's static/response caching. Runtime cost is negligible relative to content queries and is dominated by Statamic core behavior, not by this package. Scaling risk here is zero; the risk is entirely organizational.

Failure modes

• Silent markup breakage after a Statamic upgrade — Antlers parse changes that degrade output rather than throwing. Highest-frequency failure.
• Blank/empty output from blueprint-fieldset mismatches when the tools are used outside a Peak-shaped content model.
• Abandonment — maintainer stops publishing; no upstream fix for a future Statamic major.
• License exposure discovered late — GPL obligations surface during a client delivery or a product launch, forcing a rewrite of template code under schedule pressure. This is the most expensive failure mode and the most preventable.
• Version pinning drift — a floating constraint silently pulls a breaking release into a deploy.

Ramp-up Technically shallow: a developer fluent in Antlers is productive in hours, since the surface is partials and conventions rather than APIs. The genuine ramp-up is conceptual — the package's value is inseparable from Peak's opinions about content modeling, so onboarding cost is really "learn the Peak starter kit," not "learn this package." That cost should be attributed to the Peak decision, not amortized here. For a team without Antlers experience, plan one to two days of ramp-up plus a template review pass before the first production deploy.