Phantasos Client Bundle Laravel Package

Getting Started

Reality check before you type composer require: mesd/phantasos-client-bundle is a Symfony bundle, not a Laravel package. It carries zero stars, zero dependents, and its last release was September 2017. There is no Laravel service provider, no facade, and no extra.laravel auto-discovery block. Treat this as "source you can study or vendor," not "a dependency you install into a modern Laravel app."

Minimal steps to evaluate it:

1. Open the repository and read composer.json first. Note the required PHP version (likely 5.6/7.0-era) and the symfony/* constraints. If it pins Symfony 2.x/3.x components, installing it alongside a current Laravel (which ships Symfony 6/7 components) will almost certainly cause Composer resolution conflicts.
2. Read DependencyInjection/ (the bundle extension and configuration class) and Resources/config/ (usually services.yml or services.xml). That is where the actual wiring lives — service IDs, constructor arguments, and the config tree root. This tells you more than the README will.
3. Look at the client class itself (typically under Client/ or Service/). Identify whether it wraps Guzzle, a raw cURL handler, or something custom, and what the constructor needs (base URI, credentials, HTTP client).
4. Read Tests/ if present. Fixtures and mocked responses are the fastest way to understand the expected request/response shapes.

First use case: skip the bundle entirely. Copy the client class into app/Services/Phantasos/ (or a small local package), replace its Symfony-coupled dependencies with Laravel's HTTP client or a Guzzle instance from the container, and call it from a single artisan command or tinker session against a sandbox endpoint. Confirm the API contract works before investing in integration.

Implementation Patterns

If you are actually in a Symfony app (the only environment this was designed for):

• Register the bundle in AppKernel/bundles.php, then configure it under whatever alias the extension exposes (check getAlias() in the DI extension — likely mesd_phantasos_client or similar).
• Inject the client service by its service ID rather than instantiating it. Autowiring may not work if the service ID does not match the class name — check services.yml.
• Wrap calls in your own application service so the bundle's client never leaks into controllers. This also gives you a seam to swap it out later.

If you are bridging it into Laravel (the realistic day-to-day scenario):

• Bind an interface in a service provider:

// app/Providers/PhantasosServiceProvider.php
public function register(): void
{
    $this->app->singleton(PhantasosClient::class, function ($app) {
        return new PhantasosClient(
            baseUri: config('services.phantasos.url'),
            http: $app->make(\GuzzleHttp\Client::class),
        );
    });
}

• Put credentials in config/services.php and .env (PHANTASOS_URL, PHANTASOS_TOKEN). Never hardcode the base URI the way a Symfony parameters.yml would have.
• Because the original client predates PSR-18/PSR-17 adoption, expect it to be tightly coupled to a concrete Guzzle version. If so, write a thin adapter that translates the bundle's method signatures to Laravel's Http:: facade so the rest of your code stays framework-native.
• Queue long calls. Any client of a remote "Phantasos" service is I/O-bound; wrap calls in a ShouldQueue job with retryUntil and exponential backoff rather than calling it inline in a request.
• Cache reads. For read endpoints, use Cache::remember() keyed by the request payload hash. This is the single biggest win in day-to-day use and insulates you from client flakiness.
• Test with fakes, not the client. Http::fake() in Laravel means you never need to instantiate the 2017 client in tests at all — another reason to adapt rather than depend.

Integration tips: define a PhantasosGateway interface in your domain, implement LegacyPhantasosGateway (adapts the bundle) and HttpPhantasosGateway (native Laravel HTTP). Ship the legacy one behind a config flag, and you can retire it without touching call sites.

Gotchas and Tips

• Abandoned dependency. Last release 2017, no security advisories will be issued, and transitive dependencies (old Guzzle, old Symfony) may themselves be vulnerable or unresolvable. Run composer audit and expect noise.
• Composer conflicts are the #1 blocker. Even in a Symfony app on 5.x/6.x, the pinned symfony/* versions will fight your framework. Use composer why-not and composer depends to see the conflict tree before wasting an afternoon.
• No Laravel package discovery. You must write your own provider and config. There is no php artisan vendor:publish path.
• YAML/XML DI config is not loadable by Laravel. The Resources/config/services.yml is Symfony DI syntax; do not try to parse it in Laravel. Read it as documentation of constructor arguments only.
• Naming assumptions. The service ID usually does not equal the FQCN, so Symfony autowiring silently fails. Use explicit arguments: or a compiler pass alias.
• Debugging tips:
  • Symfony: bin/console debug:container <service-id> and debug:config <alias> confirm the extension actually registered and what the resolved config tree looks like.
  • Laravel: app(PhantasosClient::class) in tinker, and log raw request/response pairs from the HTTP layer (Guzzle middleware or Http::withOptions(['debug' => true]) in a local env).
  • If the extension throws during container compile, the error message usually names the exact missing config key — read the Configuration class to see which nodes are isRequired().
• Extension points: prefer Symfony's service decoration (decorates:) or Laravel's container rebinding over forking. Decorating keeps the original intact and makes the upgrade path (or removal) trivial.
• Version pinning: if you genuinely must install it, pin an exact version and commit the lockfile. Do not allow ^ ranges to float — the package is not maintained, so the "latest available" is frozen anyway.
• Recommendation: for a new Laravel project, treat this as a reference implementation of the Phantasos API contract only. Reimplement the thin client against Laravel's Http facade in an afternoon, and you avoid an unmaintainable, zero-star, decade-old Symfony dependency.