Statamic Super Mover Laravel Package

Product Decisions This Supports

• Build vs. buy, resolved toward "buy — provisionally." The 1.0.0 tag is the first release in this package's history to carry an explicit stability contract. That converts an open-ended dependency question into a bounded one: we can adopt against ^1.0 and expect documented breaking changes only on a major bump, rather than absorbing silent churn from 0.x minor releases.
• Roadmap sequencing. A stable API means the integration work can be scheduled as a discrete, estimable task instead of an ongoing tax. If this package supports a user-facing capability, it can go into a near-term sprint without a research spike into "will this break under us next month."
• Feature scope / not-invented-here review. Any internal backlog item that this package already solves should be re-scored. A 1.0.0 with a published API is a defensible answer to "why are we maintaining our own version of this?"
• Dependency posture for shared foundations. Packages that land at 1.0.0 with a semver commitment are candidates for platform-level adoption (shared across services), whereas 0.x packages should stay scoped to a single application where a bad upgrade is contained.
• Exit-cost planning. The 1.0.0 boundary is the natural moment to write down the abstraction seam — what we'd have to reimplement if we dropped the package. This decision is cheaper to make now than after three teams depend on it directly.
• Procurement / licensing and security review. 1.0.0 is the gate most organizations use to move a dependency from "experimentation" to "approved for production." This release is the trigger for that review, not a conclusion of it.

When to Consider This Package

Consider adoption when most of the following hold:

• The capability is on our roadmap or already hand-rolled. A 1.0 dependency that replaces maintained-in-house code is a net reduction in surface area; one that adds a new capability we hadn't planned for is a scope increase and needs its own justification.
• Laravel and PHP version support matches our matrix. Check the package's CI matrix against the oldest Laravel and PHP versions we actually run — particularly if any service is on an older LTS. A 1.0.0 that supports only the newest two Laravel majors silently forces a framework upgrade.
• There is a published upgrade guide or changelog discipline. The semver promise is only as good as the maintainer's follow-through; a 1.0.0 with no changelog process is a promise without an enforcement mechanism.
• Integration footprint is conventional. Service provider with auto-discovery, publishable config, publishable migrations, no global state, no facade required in application code — the things that make a package swappable later.
• Maintainer health is adequate for the criticality. For non-critical paths, a single-maintainer package is fine. For anything on a revenue or auth path, look for multiple maintainers, recent activity, and a security contact.
• The test story is real. First-party testing helpers, and a test suite that runs against the framework versions we use, are the best available proxy for whether upgrades will be quiet.

Look elsewhere when:

• The package is a thin wrapper. If the value is under a few hundred lines of glue over a first-party Laravel or Symfony component, the dependency costs more in review and upgrade time than the code it saves.
• Laravel first-party covers it, or covers it on the published roadmap. A first-party solution arriving in the next LTS makes a third-party dependency a planned migration.
• It reaches into internals — overriding framework behavior, patching service container resolution, or depending on undocumented Eloquent/Query Builder behavior. These break on Laravel minors regardless of the package's own semver discipline.
• It is on a critical path with a single maintainer and no fallback. 1.0.0 does not mitigate bus factor.
• A 1.0.0 with no prior public releases means there is no upgrade history. We would be the first cohort to test the maintainer's semver discipline. That's acceptable for a contained integration, not for a platform-wide standard.

How to Pitch It (Stakeholders)

For executives: We're evaluating a Laravel package that has just reached its 1.0.0 release. In practice, that's the milestone where a library stops being an experiment and starts making commitments: the maintainer is now on record that future breaking changes come only with a major version bump, which means we can plan around it rather than re-testing it every few weeks. The decision it unblocks is build-versus-buy — whether we adopt this instead of maintaining equivalent code ourselves. The case rests on three things: it removes code we'd otherwise own and staff; the integration is small enough to reverse if it disappoints; and the version contract lets us schedule the work instead of treating it as ongoing risk. What 1.0.0 does not tell us is whether the maintainer will honor that contract, how responsive they are to security reports, or whether the project survives its current maintainers. I'd recommend a bounded pilot in one service, with the abstraction seam documented up front, before anything broader.

For engineering: The headline is that the API is now stable and ^1.0 is a safe constraint. Before we commit, we need four things confirmed: the supported Laravel/PHP matrix against our oldest running versions; whether the integration is limited to a service provider, config, and migrations, or whether it hooks into framework internals; what the test helpers look like, since that predicts how painful upgrades will be; and where the seam is — the interface or adapter behind which we'd hide it, so a future replacement is a contained change. Because this is the first public release, we have no upgrade history to learn from; the honest plan is to adopt it in one service, pin the constraint, and watch the first minor release to see how the changelog and deprecation process actually work in practice. If the capability overlaps with something Laravel is likely to ship first-party, flag that now rather than after adoption.