Medusa Api Client Laravel Package

Product Decisions This Supports

• Build vs. buy for commerce integration: If Medusa (headless commerce) is on the roadmap, this package is a candidate to avoid writing your own PHP API client. At v0.1.x it is a thin, low-commitment dependency rather than a platform bet — suitable for a spike or internal tool, not yet for a revenue-critical storefront without pinning and a fallback plan.
• Framework lifecycle / upgrade planning: The v0.1.2 release extends symfony/* constraints to ^6.4|^7.0|^8.0, which means adopting it does not block a Symfony 7 → 8 upgrade path. This removes a common "dependency holds us back" objection in roadmap discussions and reduces the risk of choosing it now.
• Architecture decision (Symfony bundle vs. Laravel-native): The change to AbstractBundle::loadExtension() and removal of the standalone GraciousMedusaApiClientExtension class confirms this is a Symfony bundle-style integration. PM should treat "Laravel package" expectations (service provider, facades, config publishing) as unproven until verified in code — factor that into effort estimates.
• Adoption timing: v0.1.2 is a maintenance/compatibility release with no new features. It improves the "can we adopt this without upgrading Symfony first" answer, but does not change the maturity signal — still pre-1.0, so budget for breaking changes.

When to Consider This Package

Consider it when:

• Your commerce backend is Medusa and your application layer is PHP (Laravel or Symfony).
• You need a maintainable HTTP client rather than hand-rolling one, and you value the maintainer tracking upstream framework releases (Symfony 8 support landed promptly).
• You are on Symfony 6.4, 7.x, or 8.x and want a single constraint that covers your upgrade window.
• You are doing an internal tool, admin integration, or prototype where 0.1.x churn is acceptable.

Look elsewhere (or wrap it) when:

• You require stable public API guarantees (1.0+), long-term support commitments, or a published deprecation policy.
• You need a Laravel-native integration (service provider, facade, config publish, Eloquent-adjacent helpers) — this release reinforces its Symfony bundle heritage.
• You subclass or reference internal classes: the removal of GraciousMedusaApiClientExtension is technically breaking. Anyone who extended or referenced that class must migrate; at 0.1.x this is expected, but confirm no internal code depends on it before bumping.
• You need proven breadth of Medusa API coverage, documentation, or a support SLA — none of which this release note evidences.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost open-source dependency that lets our PHP stack talk to Medusa instead of building and maintaining that integration ourselves. The latest release is purely maintenance — it adds compatibility with Symfony 8 and cleans up internal wiring, with no new features and no business-facing changes. Risk is contained: the project is pre-1.0, so we pin the version and treat it as an evaluated component, not a strategic commitment.

To engineering: v0.1.2 is a compatibility and housekeeping release: widened symfony/* constraints to ^6.4|^7.0|^8.0, migrated to AbstractBundle::loadExtension(), and dropped the separate extension class (internal — verify nothing references it). No functional changes. Recommendation: pin to 0.1.2, validate on our target Symfony version, and keep an abstraction layer around the client so a 0.x breaking change or a swap-out is a contained effort.