Statamic Private Media Laravel Package

Technical Evaluation

Architecture fit. This is a Statamic addon built on Laravel's service provider lifecycle. It extends Statamic's AddonServiceProvider and uses bootAddon() as its registration hook, which is the idiomatic extension point. The v0.1.1 fix is architecturally meaningful: the package previously overrode bootRoutes(), bootCommands() and bootPublishables(), while Statamic's base boot() already invokes those before bootAddon(). That produced double registration of the delivery route, the prune command, and the publishables. The corrected version defers entirely to the parent lifecycle, which is the lower-risk arrangement and signals the maintainer understands the framework contract rather than working around it.

Integration feasibility. Presumably installable via Composer with Laravel package auto-discovery, requiring a publish/migrate step and a scheduled prune. Small surface area: one route, one command, a set of publishable assets. The main integration work is configuration and scheduling, not code.

Technical risk. Low to moderate. The fixed defect was a real but bounded class of bug — duplicate route entries (ambiguous matching, confusing route:list output), duplicated command listings, and repeated publish tags. It would not typically corrupt data, but it can mask which registration is authoritative and complicate debugging. The larger risk is maturity: this is a 0.1.x package, so the public API, config schema, and publishables are not yet stable.

Key questions.

• What does the "delivery" route actually deliver, and what data does the prune command remove?
• What are the supported Laravel and Statamic version ranges, and are they tested in CI?
• Is bootAddon() the only intended extension point, or does the package expect consumers to subclass the provider?
• Was the redundant override ever load-bearing for any deployment (e.g., a Statamic version where ordering differed)?
• Is there test coverage asserting single registration — route count, command count, publishable count?

Integration Approach

Stack fit. Targets Laravel applications running Statamic. No non-standard dependencies are implied. Fits cleanly into an existing Statamic site as an addon rather than a standalone package, so it inherits the host app's routing, console, and publishing conventions.

Migration path. Greenfield installs are straightforward: require the package, publish config and any migrations/assets, run migrations, and schedule the prune command. For anyone who installed v0.1.0, this is a drop-in patch with no data or config migration — but they should verify that duplicate registrations from the earlier version have not left stale cached routes or duplicated scheduled entries.

Compatibility. The fix depends on the host Statamic version's AddonServiceProvider::boot() calling bootRoutes(), bootCommands() and bootPublishables() before bootAddon(). Pin a Statamic range known to behave that way and re-verify on Statamic minor upgrades, since addon lifecycle ordering is the exact seam this release touches. Confirm the Laravel version range against the host app's constraint before requiring.

Sequencing.

1. Install in a local/dev Statamic instance at the pinned version.
2. Run php artisan route:list and php artisan list and assert exactly one delivery route and one prune command appear.
3. Confirm the expected publishables are offered exactly once via vendor:publish.
4. Exercise the prune command against seeded data in staging, including the empty-table and large-table cases.
5. Add the prune to the scheduler with an explicit cadence, then promote to production.

Operational Impact

Maintenance. Small code surface, but pre-1.0 versioning means minor releases may carry breaking changes. Assign an internal owner and review each release note rather than floating the constraint. The v0.1.1 fix is itself a signal that registration behavior is still being stabilized.

Support. Upstream is a single maintainer path until proven otherwise; assume best-effort. Internal runbooks should cover how to inspect registered routes and commands, since that is where the fixed defect manifested.

Scaling. The delivery route plus prune command implies accumulating records or artifacts. Prune cadence is the primary scaling lever: too infrequent and storage grows unbounded; too aggressive and delivery history disappears. Size the retention window against expected delivery volume before production rollout, and monitor table growth.

Failure modes.

• Prune command never scheduled → unbounded storage growth and slowing queries.
• Duplicate registration recurring after a Statamic upgrade that changes lifecycle ordering → ambiguous routing or doubled console output.
• Publishables drifting between versions → stale published config silently overriding new defaults.
• Cached routes/config in production masking a provider change after deploy.

Ramp-up. Low for a developer already fluent in Laravel service providers and Statamic addons — roughly a half-day to install, verify single registration, and validate the prune. A TPM should budget a short verification spike specifically around the lifecycle behavior this release changed, and treat the package as early-adopter until it reaches 1.0 or accumulates a stable release history.