Statamic Super Mover Laravel Package

Technical Evaluation

Baseline note: This is the first assessment on record. The only input is a v1.0.0 initial release; no package metadata, feature list, or version support matrix was supplied. Everything below is therefore conditional, and the key questions are the deliverable — they must be answered before this package is approved for adoption.

Architecture fit. A Laravel package's fit is determined by how it hooks into the framework, not by what it does. The decisive question is whether it follows framework conventions — package auto-discovery via extra.laravel.providers, publishable config and migrations, container bindings against interfaces rather than concrete classes, events instead of hard-coded callbacks — or whether it reaches into framework internals, overrides global middleware, or requires manual bootstrap edits. The latter is survivable but couples our application skeleton to the package's lifecycle. A 1.0.0 label matters here: it declares the public API a stability contract, so any non-idiomatic surface becomes expensive to walk back.

Integration feasibility. Laravel packages are typically low-friction additions — one composer require, one service provider, one config file. Real feasibility hinges on the version matrix (PHP floor, supported Laravel majors) and on collision risk: duplicate config keys, competing service-provider bindings, or middleware ordering conflicts with what we already run. Confirm whether it requires database migrations or schema changes, since that moves it from a code dependency to a data-model dependency.

Technical risk. Three risks dominate at a 1.0.0 with no visible pre-1.0 history. First, the API is declared stable without a demonstrated upgrade path, so we cannot yet judge the maintainer's breaking-change discipline. Second, the test matrix across Laravel versions is unknown; packages frequently claim broad support while CI exercises one version. Third, blast radius: a service provider that throws during boot takes down the entire application, not just the feature. Treat "it installs cleanly" as no evidence of safety.

Key questions.

1. What problem does it solve, and is that problem on our roadmap?
2. Exact PHP and Laravel support matrix — does it cover our current LTS and the next one?
3. Does it alter the request lifecycle (middleware, global scopes), the data model (migrations), or only add opt-in services?
4. Runtime dependency or dev-only tooling?
5. License, dependency count, and transitive dependency weight?
6. CI configuration and coverage; is the test matrix visible?
7. Does a security policy and disclosure process exist?
8. Maintainer count and release cadence — what is the bus factor?
9. Is there an upgrade guide, and did the 0.x → 1.0 transition include one?

Integration Approach

Stack fit. Cannot be confirmed without the support matrix. Decision rule: if it supports the current LTS plus the prior major, it is adoptable on existing services. If it pins to the newest Laravel only, restrict it to greenfield work or accept that every framework upgrade forces a coordinated package upgrade.

Migration path. There is no migration — this is an initial release, so adoption is greenfield with no legacy surface to unwind. That is an advantage: we can evaluate it without a compatibility shim. Run a timeboxed spike on a throwaway branch, pin the exact version, publish the config, and diff the published config against our conventions before writing any application code against it.

Compatibility. Verify the composer constraint resolves cleanly against our lockfile, check required PHP extensions, and identify optional dependencies (Redis, a specific queue driver, a filesystem adapter) that imply infrastructure work. Flag anything that mutates framework behavior globally rather than per-call.

Sequencing.

1. Pin exact 1.0.0 — no caret range — during evaluation.
2. Spike in a non-production branch; exercise the failure path, not just the happy path.
3. Add integration test coverage for the package's touchpoints in our app.
4. Roll out behind a feature flag if it touches the request lifecycle or the data model.
5. Relax to ^1.0 only after one minor release ships cleanly and the changelog shows no surprises.

Operational Impact

Maintenance. Semver at 1.0.0 means patch and minor should be safe upgrades, which is a genuine operational benefit over a 0.x dependency. The caveat is that the first several 1.x minors are where undocumented behavior changes tend to surface. Budget one upgrade pass per Laravel major and subscribe to release notifications rather than discovering changes at upgrade time.

Support. Unknown until asked. Issue response time, release cadence, and whether security reports have a private channel are the three signals that separate a maintained package from an abandoned one. A single-maintainer package is acceptable for non-critical paths and unacceptable for anything in the request lifecycle or auth stack.

Scaling. Depends entirely on placement. If it introduces per-request middleware work, additional queries, or synchronous calls to external services, it needs load testing at expected peak before rollout. If it is a behind-the-scenes service used by background jobs, scaling risk is near zero.

Failure modes. Ranked by severity: (1) service provider boot exception — full application outage; (2) config cache incompatibility — works in local, fails in production after config:cache; (3) migration collision or rollback ordering issues; (4) silent no-op when package discovery is disabled in a deployment, producing behavior that differs between environments; (5) transitive dependency conflict blocking an unrelated security patch.

Ramp-up. Low if conventions are followed — an experienced Laravel engineer should be productive in under a day. Realistic estimate is half a day of spike plus one to two days for integration tests and documentation of the config surface. Assign a named owner, record the pinned version and upgrade policy in the dependency register, and document the config keys we actually set so the next upgrade is a diff rather than an investigation.