- Is exsyst/worker-bundle a Laravel package?
- No. exsyst/worker-bundle is a Symfony2 bundle that wires the EXSyst Worker component into Symfony's dependency injection container. Laravel has no bundle, DI extension, or compiler-pass concept, so the package does not map to Laravel's architecture. Laravel teams should treat it as a Symfony-only integration.
- Can I install exsyst/worker-bundle in a Laravel application?
- You can require it with Composer, but it will not integrate with Laravel automatically or provide usable worker wiring. There is no Laravel service provider, facade, config publishing, or package discovery support. Making it work would require a custom compatibility layer, which is not recommended.
- What does EXSyst WorkerBundle actually do?
- It integrates the EXSyst Worker component into Symfony applications through a Symfony DI extension, compiler pass, and tagged service registration. The bundle itself is mostly service wiring; the worker runtime comes from the underlying EXSyst Worker component. None of that Symfony-specific wiring exists in Laravel.
- Which Symfony and PHP versions does exsyst/worker-bundle support?
- The package is Symfony2-era and the Travis .org badge points to an old CI setup. Symfony 2 reached end of life in November 2018, and the bundle likely predates PHP 8 support. Check its Composer constraints before considering any use, but do not expect modern Laravel or PHP compatibility.
- How do I configure workers with exsyst/worker-bundle?
- Configuration is done through Symfony bundle registration in AppKernel plus services.yml definitions and tagged services for the compiler pass. There are no Laravel config files to publish and no Laravel service provider to register. In Laravel, configure queue connections and run workers with queue:work instead.
- Does exsyst/worker-bundle support Laravel package discovery?
- No. It has no Laravel service provider, contracts, facades, or config/publish tags, so Laravel package discovery has nothing to register. Any Laravel integration would be a custom reimplementation of the bundle's Symfony service wiring. That reimplementation would bypass most of the bundle's value.
- What is the Laravel alternative to exsyst/worker-bundle for background workers?
- Use Laravel's native queue system with the database or Redis driver and run queue:work under Supervisor. Add Horizon if you need Redis dashboards, autoscaling, and retry visibility. If a specific EXSyst Worker behavior is truly required, adopt the raw component with a small custom Laravel service provider.
- Is exsyst/worker-bundle maintained and safe for production?
- The package shows no meaningful quality signal: zero stars, zero dependents, readme-only documentation, and a dead Travis .org CI badge. It targets an end-of-life Symfony2 stack, so security and compatibility patches are unlikely. That makes it a high-risk dependency for production use.
- Can I fork exsyst/worker-bundle and make it work with Laravel?
- The Apache-2.0 license makes forking legally straightforward, but the technical work is not. You would need a Symfony-container compatibility shim and a rewrite of the bundle's service wiring as a Laravel service provider. At that point the bundle contributes little beyond a small provider around the underlying component, and you must own security patching.
- How should I test a Laravel worker integration if I try to use this package?
- You would be testing a custom compatibility layer, not the bundle's Symfony wiring. Cover job dispatch, worker startup and shutdown, failure and retry handling, and process supervision in integration tests. Because the package has zero known dependents, there is no proven Laravel test or usage pattern to reference.