Saloon Sdk Generator Laravel Package

Technical Evaluation

• Architecture fit: This is a developer-time Laravel/PHP code generator, not a runtime application dependency. It fits teams standardizing third-party API integrations through generated Saloon SDKs, reducing bespoke HTTP client code and auth handling. v1.6.0 improves alignment with Saloon’s current security baseline and generated SDK portability across Saloon v3/v4.
• Integration feasibility: Low-friction for teams already using Composer and Saloon. The generator remains a global CLI install, while generated SDKs can be committed/published as internal packages with saloonphp/saloon: ^3.0|^4.0. This allows generator upgrades and runtime Saloon upgrades to be sequenced separately.
• Technical risk: Saloon v4 is a major version and security-driven release. The notes state no functional API changes, but major-version upgrades still warrant regression testing, especially around Laravel plugin integration, auth flows, and Composer resolution. The multi-authenticator fix changes generated auth behavior from getAuthenticator() to defaultAuth(); this is likely corrective but should be treated as a behavior change for multi-auth connectors. Runtime apps remaining on Saloon v3 retain compatibility but may not receive the security remediation implied by v4.
• Key questions:
  • What PHP/Laravel versions does generator v1.6.0 require, and do they match developer/CI environments?
  • Are generated SDKs tested against both Saloon v3 and v4 in CI, or is compatibility only declared via Composer constraints?
  • Does the multi-authenticator change require regeneration of existing SDKs to take effect, and are there auth-selection regressions?
  • Which production services are exposed to the referenced Saloon CVEs, and what is the runtime upgrade plan to v4?
  • Should the generator be pinned in CI/tooling images to prevent global Composer version drift?

Integration Approach

• Stack fit: Suitable for Laravel/PHP organizations using Saloon as the HTTP integration layer. TPM should position the generator as part of the SDK delivery pipeline: API spec changes → generated SDK → internal Composer package → application consumption. It is not a production runtime component.
• Migration path: Pin generator v1.6.0 in developer tooling/CI, regenerate a representative SDK set in a branch, and validate diffs. Existing generated SDKs do not automatically receive the multi-authenticator fix; regeneration is required. Publish regenerated SDKs with ^3.0|^4.0 constraints so consuming apps can adopt independently.
• Compatibility: Generated SDKs support both Saloon v3 and v4, which lowers immediate runtime migration pressure. The generator itself now requires Saloon ^4.0 and saloonphp/laravel-plugin: ^4.0, so tooling environments must resolve v4 even if production apps remain on v3 temporarily. Multi-authenticator connectors need targeted compatibility tests before broad rollout.
• Sequencing: 1) Inventory generator usage, generated SDKs, and runtime Saloon versions. 2) Upgrade generator tooling to v1.6.0 in a controlled environment. 3) Regenerate SDKs and review auth-related diffs. 4) Run generated SDK tests against Saloon v3 and v4. 5) Publish internal SDK updates. 6) Upgrade runtime applications to Saloon v4 where CVE exposure requires it. Avoid combining generator upgrade, SDK regeneration, and runtime major-version upgrade in a single unreviewed release.

Operational Impact

• Maintenance: Adds a versioned code-generation tool to the delivery pipeline. TPM should assign ownership for generator version pinning, regeneration cadence, generated diff review, and internal SDK release management. Global Composer installs need explicit version control in CI images or setup scripts.
• Support: Reduces long-term support burden by standardizing generated HTTP clients and auth patterns, but introduces dependency on the generator’s output quality and release cadence. Support teams should know which services use generated SDKs and which Saloon version each service resolves.
• Scaling: Strong fit for scaling many API integrations: consistent SDK structure, centralized auth behavior, and reproducible generation. Scaling requires automated regeneration checks and review gates to prevent unreviewed generated-code churn.
• Failure modes: Main risks are Composer conflicts in tooling environments, generator incompatibility with older PHP/Laravel versions, auth regressions in multi-authenticator connectors after regeneration, runtime apps remaining on vulnerable Saloon v3, and drift between generated SDK versions across services. The multi-auth fix is a specific regression-test target.
• Ramp-up: Low for teams already familiar with Saloon and Composer; moderate for teams new to generated SDK workflows and Saloon auth patterns. Provide a short runbook covering generator installation, regeneration, auth testing, SDK release, and runtime Saloon v4 upgrade criteria.