- How do I install splash/recommerce in a Laravel app if it is not published on Packagist?
- Add the self-hosted GitLab repository to the repositories array in your composer.json, then run composer require splash/recommerce. Because there is no Packagist metadata, check whether the repository carries version tags before requiring; if only dev-main exists, pin an explicit commit hash so a stray push cannot change what you deploy. Publish the package config with php artisan vendor:publish and supply the base URL and credentials through environment variables.
- Which PHP and Laravel versions does splash/recommerce support?
- The package is expected to target PHP 8.x and a Laravel 9 to 11 band, but the constraint floor should be confirmed in its composer.json before you adopt it. If it requires an older Laravel than your application runs, you are trading an upgrade problem for an integration problem. Check the Guzzle constraint as well, since a pinned major version can conflict with HTTP clients already present in your app.
- Is splash/recommerce a complete e-commerce package or just an API client?
- The overview describes a Laravel-native foundation with models and services for products, carts, checkout, orders, and returns, but the Embedded qualifier indicates it is meant to be dropped into a host application and driven in-process. In practice it reads as a service-provider-registered connector for the Splash ReCommerce OpenAPI rather than a standalone storefront or hosted service. Read the source to determine how much domain logic lives in the package versus on the remote API.
- Does splash/recommerce own migrations, models, or queue jobs in my application?
- This is one of the most important things to verify before installing, because a pure transport layer is easy to reason about while a package that ships migrations and Eloquent models couples your domain to a vendor's persistence choices. The public package record does not answer this definitively. Inspect the service provider and package directories for migrations, models, event listeners, and job classes, and budget an isolation layer if any are present.
- How do I configure the ReCommerce API base URL and credentials?
- Configuration follows the standard Laravel pattern: a publishable config file holding the base URL and credential keys, populated from environment variables so no secrets are committed. Keep separate env entries per environment and, if you run multiple storefronts or tenants, confirm the package accepts per-instance credentials rather than one global set. Check how the client is bound, because a singleton can leak one tenant's credentials into another tenant's request.
- How do I test code that depends on splash/recommerce?
- Because the package registers its client through a service provider, you can rebind it in your test suite to a fake or a Guzzle mock handler so most tests never touch the network. The open question is the package's own test posture: mocked HTTP tests prove your code handles expected responses, but only contract tests against the live OpenAPI catch renamed fields, nullable drift, and enum expansion. Ask whether the repository contains anything beyond mocked fixtures.
- Does splash/recommerce handle token refresh and multi-tenant credentials?
- Credential and token-refresh handling is frequently the least-tested part of API connectors, and the public package information does not document it. Look for an explicit refresh strategy, sensible expiry handling, and a way to inject credentials per request or per client instance. If the package assumes a single credential set, you will need your own factory layer for multi-tenant or multi-storefront deployments.
- Is splash/recommerce safe to use in production?
- The code itself may be perfectly sound, but the provenance signals are weak: it is hosted on a self-hosted GitLab instance with no Packagist metadata, no visible license field, and no dependents or issue history to mine for known failure modes. That makes it a bus-factor-of-one dependency for a revenue-adjacent integration. Treat it as a risk you mitigate with an isolation layer, a pinned commit, and a documented exit plan rather than a drop-in you trust unconditionally.
- How do I keep splash/recommerce from leaking into my controllers and domain services?
- Define your own port, such as a ReCommerceGateway interface, and implement it with an adapter that wraps the package client and translates its DTOs and exceptions into your domain types. Bind the adapter in a service provider so controllers, jobs, and domain services depend only on your interface. That single decision turns vendor lock-in into a replaceable adapter and makes any later migration mechanical.
- What are the alternatives to splash/recommerce?
- If your ReCommerce integration is small, a hand-rolled client built on Laravel's Http facade may be simpler and removes the dependency entirely. Otherwise look for an OpenAPI-generated client published on Packagist with real version tags, CI, and dependents, so you get a support trail. General Laravel commerce packages also exist, but they model their own storefront rather than speaking the ReCommerce API.