Statamic Bunny Stream Laravel Package

Technical Evaluation

Architecture fit. The release notes identify this as a Statamic addon (Statamic 5 and 6 are both explicitly referenced) built on Laravel/PHP. Its functional scope, based on the 1.1.2 notes, includes a control-panel UI concern — focal-point previews rendered inside the Statamic CP — plus a front-end/asset-pipeline touchpoint implied by "isolating the control-panel bundle from browser globals." Architecturally this is a thin addon: a CP Vue/JS bundle registered through Statamic's addon service provider, with PHP-side config and fieldtype/render logic. That is a good fit for the Laravel/Statamic ecosystem (composer-installed, no separate runtime, no additional infrastructure), but it also means the package's blast radius is concentrated in the CP asset layer, which is the least stable surface across Statamic majors.

Integration feasibility. Low-to-moderate. Installation is presumably standard composer + php artisan vendor:publish, and 1.1.2 explicitly states no configuration changes are required — a strong signal that this is a drop-in patch. The main integration work is not installation but verification: confirming focal-point previews render correctly in the CP for both Statamic 5 and 6 installations, and confirming the bundle isolation change does not break any site-level JS that previously relied on the addon's globals. That last point is the real integration risk and should be tested rather than assumed.

Technical risk. The change itself is narrow and low risk: scoping a JS bundle away from window globals is a defensive, best-practice fix. The residual risks are (a) any custom or third-party code that reached into those globals — an unusual but non-zero pattern in Statamic projects where developers patch CP behavior; (b) the dual-support burden of Statamic 5 and 6, where 1.1.2 only touches the 6 path and 5 is stated unchanged, meaning the 5 path is now effectively frozen and untested by this release; (c) the package appears to have no prior assessment on file, so we have no established baseline for its maintenance cadence, test coverage, or security posture.

Key questions. What is the package's actual name, license, and current download/install base? Does it ship automated tests against both Statamic 5 and 6 in CI, or is dual support asserted rather than verified? Which globals were previously exposed, and is their removal documented anywhere beyond one release-note sentence? Is 1.1.2 a security-adjacent fix (CP bundle leaking into global scope could theoretically be exploited by or interfere with other CP scripts) or purely cosmetic? Who maintains it, and what is the release cadence over the last 12 months?

Integration Approach

Stack fit. Presumes Laravel + Statamic (5 or 6) with the standard Antlers/Vue CP stack. No new services, queues, databases, or environment variables are introduced by this patch. Composer is the only delivery mechanism. This is as low-friction as a dependency gets: no infra change, no deploy-pipeline change, no secrets management.

Migration path. Effectively a no-op migration. Bump the composer constraint to ^1.1.2, run composer update, clear Statamic/Laravel caches (php artisan cache:clear, php artisan statamic:stache:clear, and any CP asset cache), and rebuild CP assets if the project vendors them. No config file edits, no data migrations, no content model changes. Because 1.1.2 changes only the Statamic 6 CP path, a Statamic 5 project receives the upgrade with functionally identical behavior — safe to roll forward for consistency of versioning alone.

Compatibility. Dual-track: Statamic 5 = unchanged behavior; Statamic 6 = fixed focal-point previews. PHP and Laravel version floors are not stated in the release notes and should be read off composer.json before pinning. Browser compatibility is worth a quick check since the fix concerns global-scope isolation, which can intersect with older CP browser targets.

Sequencing. (1) Pin and lock in a non-production environment. (2) Smoke-test the CP focal-point fieldtype on a Statamic 6 install — create, edit, and preview an asset with a focal point set. (3) Repeat the same smoke test on a Statamic 5 install to confirm the "unchanged" claim empirically. (4) Grep the codebase and any custom CP addons for references to the addon's former global symbols. (5) Roll to staging, then production. Total effort: hours, not days, assuming step 4 comes back clean.

Operational Impact

Maintenance. Near-zero recurring cost. No config drift, no schema, no scheduled jobs. The one maintenance signal to watch is the Statamic 5 / 6 split: once a package starts branching behavior by major version, each upstream Statamic release becomes two regression surfaces. Budget for re-verification on every Statamic major and minor CP change, not just on addon releases.

Support. Support burden is concentrated in the CP, where users notice visual regressions immediately and report them loudly. The 1.1.2 fix is the kind of issue that generates a small burst of tickets ("focal point preview broken after Statamic 6 upgrade") and then goes quiet. Worth confirming the package has an issue tracker and a named maintainer before depending on it in a client-facing build.

Scaling. Irrelevant at the infrastructure layer — the addon does no runtime compute on the request path beyond fieldtype rendering. Scaling concerns are entirely about editor count and asset volume in the CP, which is a Statamic concern, not this package's. No action needed.

Failure modes. (a) Silent CP breakage on a future Statamic release, surfacing as a blank or misaligned focal-point preview rather than an exception — hard to catch without an explicit visual test. (b) Global-symbol removal breaking bespoke CP customizations, which will fail loudly in the browser console. (c) Version skew in multi-site or multi-app estates where one app is on Statamic 5 and another on 6, producing divergent CP behavior from the same lockfile version. Mitigation for all three: an explicit CP smoke test in the release checklist and a documented rollback pin.

Ramp-up. Minimal for any developer already fluent in Statamic addons — the change is a one-line composer bump and a CP click-through. The ramp-up cost that does exist is discovery cost: because there is no prior assessment and the release notes are one sentence, someone needs to spend half a day reading composer.json, the changelog history, and the diff to establish the baseline this assessment currently lacks. That investigation is the recommended next action before this package is treated as an approved dependency.