- What does koderoff/enqueue-extra-bundle actually do?
- It is a Symfony bundle that adds a thin convenience layer on top of php-enqueue, letting you declare transports and consumers via bundle configuration instead of writing glue code by hand. It registers producers and processors into the Symfony Dependency Injection container and supports multiple transports in one application. The value it adds is configuration sugar and DI wiring, not new messaging primitives. It is a Symfony bundle, so its lifecycle and wiring model are specific to Symfony, not Laravel.
- Can I use this bundle in a Laravel application?
- No, not as a drop-in dependency. Laravel has no bundle lifecycle, no bundles.php, no Extension::load() and no tagged-service autoconfiguration, so the bundle's services never register and it contributes zero runtime behavior. You would have to hand-write a Laravel service provider that re-implements the Symfony DI extension, which is unbounded work with no upstream to diff against. The correct seam for Enqueue in Laravel is enqueue/laravel-queue or a first-party Laravel queue driver.
- Does composer require koderoff/enqueue-extra-bundle work on Laravel 10 or 11?
- Most likely it fails. This is a 2020-era bundle that constrains symfony/framework-bundle, symfony/dependency-injection and PHP to 7.x-era ranges, which conflict with Laravel 10 or 11 on PHP 8.1+. If it only resolves via --ignore-platform-reqs or manual constraint overrides, treat the result as a vendored fork rather than a supported dependency. Run a dry-run install against your actual lock file before spending any engineering time on it.
- Why does installing the package not register any transports or consumers in Laravel?
- Because all of the wiring lives in Symfony bundle machinery: the DI extension, the configuration tree and the compiler passes. Laravel never invokes any of that, so no producers, consumers or transport services are bound into the container. The only reusable asset would be framework-agnostic code beneath the bundle glue, and it is unclear whether any of it exists independently of Symfony's ContainerInterface and EventDispatcherInterface. Inspecting the source for PSR-4 classes free of Symfony contracts is the first thing to check.
- Is this package safe to run in production?
- It is not recommended. There have been no releases since May 2020, meaning no security patch cadence and no advisory feed, and as a messaging component it sits on a trust boundary involving serialized payloads, broker credentials and transport configuration. With zero stars, zero dependents and no downstream consumers, regressions have no one to surface them. For experimental or internal prototypes only, and even then consider it a vendored fork you own.
- What is the maintenance status of koderoff/enqueue-extra-bundle?
- It is effectively abandoned. It has a low adoption profile, minimal documentation, no release since 2020-05-17 and an aggregate score of zero. There is no signal of an active maintainer and no ecosystem of dependents to absorb the cost of a fork. Symfony 6 and 7 also removed or deprecated several DI patterns that 2020-era bundles rely on, so it likely does not boot cleanly on modern Symfony either.
- What should I use instead for message queues in Laravel?
- Use enqueue/enqueue as the core with enqueue/laravel-queue as the bridge if you specifically need Enqueue semantics. Otherwise Laravel's first-party queue with a broker driver is the better fit: php-amqplib for RabbitMQ, Redis with Horizon, or SQS. Choose based on which transport the extra bundle was wrapping rather than on the bundle itself. The convenience features it offered are typically re-implementable in a Laravel service provider in days against maintained primitives.
- Is there a maintained fork or successor package with the same features?
- There is no known active fork or successor for this specific bundle. The upstream ecosystem it builds on, php-enqueue, is the maintained surface, and it already has a Laravel integration path. Before forking, check whether this bundle is itself a fork of an upstream Symfony bundle, since a still-maintained upstream would make this package entirely redundant. If you do fork, budget for re-validating the DI layer against a current Symfony or porting the logic to a Laravel provider.
- How would I port this bundle's behavior into a Laravel service provider?
- First isolate what the extra layer actually adds over enqueue/enqueue-bundle: a transport type, middleware, retry or delay semantics, or only configuration sugar. Register those primitives as singletons in a Laravel service provider and bind transport configuration through a config file and a config tree equivalent. Then re-implement consumers as queue workers or Artisan commands so they integrate with Laravel scheduling and supervision. Validate with tests that pin the behavior, because there is no upstream to diff against.
- Are there tests I can rely on before committing to this package?
- The package is low-adoption with minimal documentation, so do not assume meaningful coverage of the extra behavior. Check whether the repository has tests and CI that pin transport registration and consumer dispatch, since without them a port would only be validated against production traffic. If coverage is thin, write characterization tests around the framework-agnostic classes you intend to reuse before refactoring. Also confirm the license and provenance so a fork stays compliant.