- What does sroze/enqueue-bridge actually do?
- It is a small integration layer that connects Enqueue, a PHP messaging abstraction with multiple queue transports, to Symfony's Messenger component. In practice it lets you publish and consume messages through supported transports with minimal configuration instead of wiring the two libraries together yourself. It is a bridge package, so its behavior depends on both Enqueue and Messenger versions sitting on either side of it.
- How do I install sroze/enqueue-bridge in a PHP project?
- Install it with Composer using composer require sroze/enqueue-bridge, but prefer an exact constraint such as 0.2.0 over a caret range. Because the package is pre-1.0 and has no changelog, review the resolved dependency tree before committing the lock file. There is no documented Laravel service provider or config publish step, so expect to write the glue yourself.
- Is sroze/enqueue-bridge compatible with Laravel 10 or Laravel 11?
- There is no published compatibility matrix for Laravel or PHP versions, and the package targets Symfony Messenger rather than Laravel's queue component. Treat Laravel support as unverified and prove it in a time-boxed spike against your exact PHP and Laravel majors. Do not assume that a clean Composer install means runtime compatibility.
- Why does version 0.2.0 say "Last known working bridge before moving it"?
- That release note reads as an end-of-life or relocation marker rather than a normal feature announcement. It suggests the maintainer intended to move, replace, or retire the bridge, but the note does not say whether that means a rename, a new vendor, or removal without a successor. Because no changelog or migration note was published, you cannot tell from the tag alone what changed functionally.
- Is sroze/enqueue-bridge safe to use in production?
- For a new production dependency the risk profile is poor: it is pre-1.0, has no stated backward-compatibility policy, no changelog, and a release note signalling the maintainer is moving on. Abandonment and API-instability risk are high, and a frozen adapter can break when Enqueue or Messenger changes underneath it. If you must use it, pin the exact version, vendor or mirror the source, and isolate it behind your own interface.
- What Composer version constraint should I use for sroze/enqueue-bridge?
- Use an exact pin such as 0.2.0 instead of a caret constraint like ^0.2. Under 0.x versioning a caret range can still resolve to breaking changes, and there is no changelog to help you review them. An exact pin plus a committed lock file is the only defensible constraint for a package in this state.
- How do I keep the bridge from spreading through my codebase?
- Define a small first-party interface, such as a message publisher or gateway contract, and bind the bridge implementation in a single service provider. Every call site depends on your interface rather than on Enqueue or Messenger classes, so the package appears in exactly one place. Swapping to a successor or to Laravel's native queue then becomes a one-file change instead of a codebase-wide edit.
- What are the alternatives to sroze/enqueue-bridge?
- If you are on Laravel, the native queue system with Redis, SQS, or database drivers covers most publish-and-consume needs without a third-party bridge. If you specifically need Enqueue transports, use the underlying enqueue packages directly and write a thin adapter you control. If you need Symfony Messenger semantics, evaluate Messenger itself or a maintained transport integration rather than a frozen bridge.
- Does sroze/enqueue-bridge work with Laravel queue workers or Horizon?
- No. The package bridges Enqueue and Symfony Messenger, not Laravel's queue contract, so Laravel workers and Horizon do not know how to process its messages out of the box. You would need custom glue to dispatch and consume through Laravel's queue API, and that glue becomes your code to maintain. Verify this in a spike before designing around it.
- How should I evaluate sroze/enqueue-bridge before adopting it?
- Time-box a spike: pin 0.2.0, install it in a throwaway branch, and test publish and consume against the exact transport, PHP, and framework versions you run. Inventory whether anything in your estate already depends on it directly or transitively, and check whether the far side of the bridge is also moving. If the spike succeeds, vendor or mirror the source and wrap it behind your own interface before shipping.