Product Decisions This Supports
- Build vs. buy for API integrations: This package wraps Saloon for Laravel, so teams can standardize outbound HTTP integrations instead of hand-rolling clients, retries, auth, and test doubles. That shortens time-to-market for features that depend on third-party APIs.
- Feature and roadmap sequencing: The v3.0.0 upgrade to Saloon v4 is a dependency-level breaking change. Any roadmap item that adds or modifies API integrations should account for a short test-suite migration before new integration work lands.
- Release risk and maintenance planning: The only documented breaking change is fixture naming in tests (dots no longer allowed in Saloon fixture names). This is a test-harness concern, not a runtime behavior change, so product risk is low but CI reliability risk is real if fixtures aren’t renamed.
- Use cases: Server-side integrations where Laravel is the host application — authenticated API clients, request/response abstraction, recorded fixtures for deterministic tests, and connector-style features that would otherwise become bespoke code in each service.
- Vendor and dependency hygiene: Pinning to
saloonphp/saloon ^4.0 and saloonphp/laravel-plugin ^4.0 aligns the product with the current major line, avoiding a future forced upgrade combined with unrelated feature work.
When to Consider This Package
Consider adoption when:
- The product is a Laravel application and the team wants a consistent, testable pattern for outbound API calls rather than per-integration custom code.
- Engineering values fixture-based HTTP testing; the v3.0.0 fixture naming change is manageable and the team can audit and rename affected fixtures (
chat.create → chat/create).
- You are already on Saloon v3 and want to stay current; this release is the migration path, not a new capability.
- The integration surface is moderate and mostly synchronous request/response, where Saloon’s abstractions pay off.
Look elsewhere when:
- The application is not Laravel-first, or the team prefers an official vendor SDK with first-party support guarantees.
- Requirements center on streaming, long-running jobs, or high-throughput concurrency where a thin HTTP client or queue-native design is a better fit.
- The team cannot absorb a major-version dependency bump during the current release cycle; deferring means staying on Saloon v3 and accepting eventual upgrade debt.
- The integration portfolio is tiny (one or two endpoints), where a package adds indirection without meaningful savings.
How to Pitch It (Stakeholders)
For executives: This release is a maintenance upgrade, not a new product capability. It moves the package onto Saloon v4. The user-facing risk is low; the concrete impact is limited to test fixtures, where dotted names must become slash-separated. Expect a small, bounded engineering task — audit test fixtures, rename, run CI — best scheduled in a maintenance window rather than alongside a feature launch. The strategic value is keeping our integration layer on a supported dependency line, which reduces the chance of a larger, riskier upgrade later.
For engineering: Treat v3.0.0 as a breaking upgrade gated by your test suite. Bump saloonphp/saloon and saloonphp/laravel-plugin to ^4.0 together, grep for MockResponse::fixture( calls using dot notation, and rename them to slash notation. Verify no fixture filenames contain dots, since Saloon v4 rejects them. Run the full integration test suite in CI before merging. No runtime API changes are documented, so failures should point to fixture resolution rather than application logic.
Recommendation: Adopt v3.0.0 on a planned branch, complete the fixture rename, and merge once CI is green. Do not bundle it with active feature work, and do not defer indefinitely — staying on Saloon v3 creates compounding upgrade cost.