- Can I use mesd/phantasos-client-bundle in a Laravel application?
- No, this is a Symfony bundle, not a Laravel package. It follows the Symfony DI-extension pattern with a DependencyInjection extension, a Configuration tree, and services.yml, and ships no Laravel ServiceProvider, Facade, or config/phantasos.php file. There is no drop-in install path for Laravel, so you would need a hand-written bridge or a native re-implementation against the same remote Phantasos contract. Composer will also refuse resolution on modern Laravel because of the old PHP and symfony/framework-bundle constraints.
- How do I install mesd/phantasos-client-bundle in a Symfony app?
- For a legacy Symfony application you would run composer require mesd/phantasos-client-bundle, register the bundle in AppKernel or bundles.php, and set your client options under the bundle key in config.yml. The last published release is from 2017-09-27, so expect constraint conflicts against anything modern. Check the package's composer.json before assuming any constraint range, since the pins are the deciding factor for installability.
- Which Symfony and PHP versions does this bundle support?
- Based on the single 2017-09-27 release, the bundle targets the Symfony 2.8 and 3.x era and PHP 5.6 through 7.1. That is well behind modern Laravel 9, 10, and 11, which require PHP 8.1 or newer and current Symfony components. Read the actual composer.json to confirm the exact pins, because they determine whether the package can be installed at all without a fork.
- Is it safe to install with --ignore-platform-reqs in production?
- No, forcing the install simply defers the incompatibility to runtime, where it surfaces as fatal errors or subtle behaviour changes in production. The safer options are to fork the MIT-licensed bundle and relax the PHP and Symfony constraints, extract the client logic into a Laravel-native package, or skip the bundle and build against the upstream Phantasos API directly. All three avoid shipping a dependency that Composer itself says does not fit your stack.
- What does mesd/phantasos-client-bundle actually do?
- It provides Symfony container wiring for the Phantasos PHP client: service registration, configurable client options, and autowiring-friendly service definitions. In practice you configure it once and inject a ready-to-use client into your services and controllers instead of wiring HTTP transport and credentials by hand. The bundle is the integration layer, not the API contract itself, so the real value to port is the endpoints, auth, DTOs, and error handling the client encodes.
- How do I configure the Phantasos client options in this bundle?
- Configuration goes through the bundle's Symfony Configuration tree, so options live in config.yml or a file under config/packages/ and are injected into the registered client service. You then autowire or explicitly reference that service in your controllers and services. If you port the concept to Laravel, the equivalent is a publishable config/phantasos.php plus a ServiceProvider binding the client as a singleton.
- Is mesd/phantasos-client-bundle still maintained?
- No. It has a single 2017 release, zero stars, zero dependents, and no CI or security-response signal, so treat it as an orphaned reference implementation rather than a living dependency. The knowledge is concentrated in the original MESD authors and the repository reads as a one-off integration for a specific deployment. Because you would own any transitive vulnerability, such as an unpatched Guzzle of that era, adoption as a dependency is not recommended.
- What authentication model does the Phantasos client use?
- That is not confirmed by the public package metadata and is the largest unknown for planning a port. It could be a simple API key, OAuth, signed requests, or an LTI/SSO flow, and the answer changes how much logic you must reproduce. Read the bundle source, or better, obtain an OpenAPI or contract specification from the service owner before committing to a Laravel-native client.
- How do I migrate a Symfony-only Phantasos client to Laravel?
- Start with an extraction spike: read the bundle source and map every endpoint, header, and DTO into an internal contract document so you know whether it is a thin HTTP wrapper or contains signature and auth logic. Then scaffold a native Laravel package with a ServiceProvider, publishable config/phantasos.php, an HTTP client with timeouts and retries, typed DTOs, and a facade bound to the same remote contract. Add contract tests against recorded fixtures so future upstream API drift is detectable, and only then layer on caching and circuit breakers for production.
- Are there alternatives to mesd/phantasos-client-bundle for Laravel?
- Yes, and all of them are more realistic than adopting the bundle on Laravel. You can build a native client directly against the upstream Phantasos API, fork the bundle under its permissive MIT license and modernize it for Symfony 6 or 7 if you are Symfony-first, or extract the protocol logic into a Laravel package you control. The bundle itself only makes sense if you are maintaining a legacy Symfony 2.8 or 3.x application that already depends on it.