Mistral Laravel Package

Technical Evaluation

Architecture fit. The package is a Laravel service-provider package wrapping Saloon (saloonphp/saloon + saloonphp/laravel-plugin), i.e. a typed, testable HTTP-connector layer. That aligns well with Laravel conventions — container bindings, publishable config, fixture-based test doubles. Caveat: this assessment is derived solely from the v3.0.0 release notes; the package's own endpoint surface, DTOs, and auth flows are not evidenced here and must be confirmed from its README.

Integration feasibility. High for greenfield. Materially constrained for existing v2 consumers, because the release is a hard major bump on a foundational dependency. Two distinct workstreams: (a) the Saloon ^3.x → ^4.0 bump, which is all-or-nothing per application (Saloon v3 and v4 cannot coexist in one Composer install), and (b) a mechanical but repo-wide fixture rename from dot-separated to slash-separated names.

Technical risk. Primary risk is dependency-graph collision: any other package in our estate pinning saloonphp/* to ^3.x blocks this upgrade until it moves. Secondary risk is test-suite breakage from the fixture convention change — failures will surface at the test layer and can easily be misread as API/integration failures. Third risk is unstated behavioral deltas: the notes disclose no runtime changes, but Saloon v4 itself may carry breaking changes (middleware, retry/auth semantics, response handling) that this package absorbs silently.

Key questions.

• What other internal or third-party packages in our applications constrain saloonphp/saloon? Do we have a full inventory?
• Are there other breaking changes bundled into this major beyond the Saloon bump and fixture rename?
• Does a v2 maintenance branch exist for teams that cannot move to Saloon v4 on our timeline?
• Are fixture names ever constructed dynamically (config, loops, concatenation), which would defeat a simple search-and-replace?
• What is the package's supported Laravel/PHP matrix under v3?

Integration Approach

Stack fit. Standard Laravel package: Composer 2, service provider registration, publishable config. Confirm the Laravel and PHP version constraints in the v3 composer.json match our platform before committing to a rollout window.

Migration path.

1. Inventory Saloon usage across applications and composer.lock files.
2. Upgrade saloonphp/saloon and saloonphp/laravel-plugin to ^4.0 first, resolving conflicts in isolation.
3. Bump this package to ^3.0.
4. Repo-wide rename MockResponse::fixture('chat.create') → MockResponse::fixture('chat/create'), including any dynamically assembled fixture paths.
5. Re-run the full test suite and smoke-test against a sandbox endpoint.

Compatibility. Cutover is per-application, not incremental within an application — the Saloon version bump cannot be partially applied. Treat the dependency bump and fixture rename as one atomic PR so the lockfile churn and test fixes land together.

Sequencing. Pilot on the lowest-traffic internal application, then CI, then shared services, then customer-facing surfaces. If a partial rollout is unavoidable, gate the package version behind an environment-specific composer.json constraint rather than attempting to mix Saloon majors.

Operational Impact

Maintenance. This package will track Saloon majors, so plan for a recurring upgrade cadence rather than a one-off. Add a standing dependency-review checkpoint for saloonphp/* so the next bump is anticipated, not discovered.

Support. The fixture convention change needs an internal written standard (slash-separated fixture paths) plus updates to onboarding docs and any test-scaffolding templates. Otherwise new tests will reintroduce the dot convention and fail.

Scaling. No runtime scaling implications from this release — Saloon is per-request client code. Capacity concerns stay where they belong: outbound request volume and rate limits against the target API.

Failure modes.

• Composer resolution failure blocking unrelated work in a shared monorepo.
• Missed or dynamically constructed fixture names producing confusing test failures.
• Saloon v4 behavioral differences (retries, auth middleware) that only manifest in production if fixture coverage is thin.
• Silent absorption of a transitive major by an unrelated package that also depends on Saloon.

Ramp-up. Low for developers already using Saloon; medium for others, who need both the Saloon v4 documentation and this package's own README. Budget a short internal walkthrough covering the connector/request pattern and the new fixture naming rule before the first migration PR.