Pact Provider Bundle Laravel Package

Product Decisions This Supports

• Consumer-driven contract testing for Laravel services. This package wraps Pact PHP provider-side verification in Laravel conventions (service provider, config, artisan command, PHPUnit integration), so a Laravel API can prove it still honours the contracts its consumers publish. That directly supports a "test contracts in CI instead of maintaining a brittle shared integration/staging environment" decision.
• Build vs. buy (build vs. adopt). It removes the glue code a team would otherwise write by hand: Pact PHP bootstrap, provider-state / state-handler wiring, base URL and mock-server configuration, and CI-friendly exit codes. Adopt rather than build when the team's integration test suite is already PHP/Laravel and you do not want a Pact-specific harness as bespoke internal tooling.
• Roadmap input for integration/test infrastructure. It only covers the provider half. A roadmap that commits to contract testing still needs a consumer-side story (Pact JS/PHP/JVM in each consumer repo), a Pact Broker (or equivalent) plus version selectors and can-i-deploy, and a publishing policy in CI. Budget those as separate line items.
• Use cases it unlocks: safe, frequent deploys of a Laravel monolith or service consumed by mobile/web/partner clients; decoupling release cadence between provider and consumers; replacing slow, flaky end-to-end environments for a subset of integration risk; catching breaking response-shape changes (removed field, type change, status code change) before merge.
• Maturity signal from this release: v1.0.4 contains only chores — renamed test handlers, a docs return-type fix, an internal refactor and test renames. No API changes, no deprecations, no behavioural change. Read this as stable and low-churn, not actively growing: treat feature velocity and roadmap responsiveness as unresolved questions to validate with the maintainer.

When to Consider This Package

Consider it when:

• The provider is a Laravel/PHP application and consumers can realistically publish Pact contracts (or already do).
• You have — or are willing to stand up — a Pact Broker or compatible contract registry, plus CI wiring for can-i-deploy.
• You need provider states (seeded fixtures, authenticated contexts, specific DB rows) and want them expressible as Laravel-side handlers rather than a bespoke script.
• You want contract verification to run as a first-class step in the existing PHPUnit/CI pipeline with no new language runtime in the build.
• You want the escape hatch of also running Pact PHP directly — the package is a thin bundle over Pact PHP, so it is not a lock-in-heavy abstraction.

Look elsewhere or defer when:

• The provider is not PHP/Laravel — use the official Pact library for that stack; do not force a sidecar.
• You need consumer-side test generation only; this is the provider verifier.
• Your org has no appetite for a broker and no plan to version contracts; contract testing without a registry degrades into hand-managed files.
• You require commercial support, an SLA, or a multi-maintainer guarantee. This is a small, largely single-maintainer open-source project; a v1.0.4 that is all chores is a reminder to check issue responsiveness, release cadence and Pact PHP/Pact specification version support before betting a critical path on it.
• Licence, security-patch cadence and transitive dependency health have not been reviewed — do that before adoption regardless.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can verify that our Laravel API still honours the contracts our client apps depend on, on every pull request, without spinning up a full integration environment. This package is the standard Laravel wrapper for Pact, the industry-standard contract-testing tool, so we are adopting a well-understood approach rather than inventing one. The cost is low: a configuration file, a handful of provider-state handlers, and one extra CI step. The return is fewer "it worked in staging" incidents and the ability to ship the provider and its consumers on independent schedules. The main risk is not technical but organisational — it depends on consumers publishing contracts and on a broker to store them, and on a small open-source project we should treat as a dependency to monitor rather than a vendor to rely on.

For engineering leads: The package is a thin, Laravel-idiomatic bundle over Pact PHP — service provider, publishable config, artisan verification command, PHPUnit integration, and provider-state handlers we control. v1.0.4 is a chores-only release (test renames, a docblock fix, an internal refactor): no breaking changes, no deprecations, no new surface — evidence of stability, but also that we should pin a version and track upstream ourselves. Ask: which consumers can publish contracts in the next quarter, who owns the broker, and what is our can-i-deploy gate? If those three answers exist, adoption is a small, reversible bet.