- Is paloma/client-bundle a Laravel package?
- No. paloma/client-bundle is a Symfony bundle built for the Symfony dependency injection container, HTTP kernel, and event dispatcher. It ships no Laravel service provider, facade, or package discovery metadata, so Composer will install it but Laravel will not auto-wire any of its services. Treating it as a Laravel package will mis-set expectations across a Laravel team.
- Can I install paloma/client-bundle in a Laravel application?
- Technically you can run composer require, but practically it is a poor fit. Its Composer constraints target PHP 7.x, Symfony 3.4 or 4.x, and Guzzle 6.x, which will almost certainly conflict with a modern Laravel app on PHP 8.2+ and Guzzle 7. Even if resolution succeeds, the bundle contributes only a thin HTTP wrapper you would have to instantiate and configure by hand. The recommended path is a first-party adapter against Paloma's REST API using Laravel's Http facade or a PSR-18 client.
- What Symfony and PHP versions does paloma/client-bundle support?
- The bundle is built for Symfony 3.4 and 4.x on PHP 7.x, with Guzzle 6.x as its HTTP layer. Those constraints put it well behind current Laravel and Symfony baselines on PHP 8.2 and Composer 2. Expect dependency resolution failures or forced pins if you try to mix it into a current application.
- Is paloma/client-bundle still maintained?
- No. The upstream repository is archived, the last release was 2019-04-17, and it has zero stars and zero dependents. Archived code receives no security advisories, no PHP 8 compatibility fixes, and no upstream API contract guarantees. Any defect you encounter becomes your permanent responsibility.
- What does paloma/client-bundle actually do?
- It wires a PHP client for Paloma Middleware into a Symfony application by registering services, exposing a paloma_client configuration tree, and adding Twig helpers. Paloma Middleware itself is a Node.js message and event store that fronts MongoDB or Cassandra. The reusable part of this repository is essentially one class that wraps Paloma's REST endpoints over HTTP.
- How do I configure paloma/client-bundle in a Symfony application?
- You register the bundle in AppKernel or bundles.php, then add a paloma_client configuration block that the bundle's configuration tree reads during container compilation. Service wiring is handled through CompilerPass implementations, and Twig helpers come from the bundle's extension. None of this mechanism exists in Laravel, so the configuration cannot be ported directly.
- Does paloma/client-bundle work with Laravel 10 or Laravel 11?
- No. Laravel 10 and 11 assume PHP 8.1+ or 8.2+ and Guzzle 7, while this bundle pins Symfony 3.4 or 4.x, PHP 7.x, and Guzzle 6. There is no service provider, facade, package discovery, or publishable config, so Laravel has no mechanism to load it. Classifying it as Laravel-compatible for planning purposes would be inaccurate.
- What should I use instead of paloma/client-bundle in Laravel?
- Write an internal interface such as MessageStoreClient that expresses only the operations your domain needs, like publish, fetch, and acknowledge. Implement it against Paloma's documented REST API using Laravel's Http facade or a PSR-18 client with explicit timeouts, retries, and a circuit breaker. Bind the interface in a service provider you control so the only third-party surface is an HTTP contract. For event sourcing or audit logging, also evaluate maintained options like EventSauce, a managed event bus, or plain Eloquent and queue patterns.
- How do I test a Paloma integration without the bundle?
- Fake the HTTP layer rather than the bundle. In Laravel, use Http::fake to stub Paloma's REST responses and assert the request shape, retries, and error handling in your adapter. Add contract tests that pin the exact endpoints and payloads you depend on, since the archived upstream gives you no API guarantees. This keeps your test suite independent of an unmaintained Symfony package.
- Is it safe to run paloma/client-bundle in production?
- Running it in production is not advisable. The repository is archived, Guzzle 6 is end-of-life, and TLS and stream-handler behavior on current PHP runtimes is unvalidated. With zero dependents there is no community signal, no fork maintaining a compatible branch, and no bug reports telling you what breaks. You also need a live Paloma cluster, which is a second data platform to operate, so the operational cost far exceeds the value of the client wrapper.