Stomp Bundle Laravel Package

Product Decisions This Supports

• Transport selection for async work. This package is a concrete input to the STOMP vs. AMQP vs. Redis vs. database-queue decision when scoping background jobs, event fan-out, or service-to-service messaging. STOMP earns its place only when the broker is already STOMP-native — ActiveMQ Classic, Artemis, HornetQ, or RabbitMQ via the STOMP plugin — typically because a Java or .NET estate already runs it. In that scenario STOMP is the shortest path from PHP into existing infrastructure; in every other scenario it is a detour.

• Build vs. buy, answered decisively. For the framework-integration layer specifically, this package is the buy option, and it is effectively unavailable: 1 star, 0 dependents, no release activity, and a Symfony2 target that has been end-of-life since 2018. That closes the buy branch and pushes the decision to build — either a thin adapter over the current stomp-php client or, better, adoption of a maintained client such as enqueue/stomp. The important PM outcome is that the decision gets made deliberately rather than by a developer quietly adding a dead dependency.

• Scope definition for that in-house adapter. It documents the minimum viable integration surface: connection factory configuration, per-connection credentials, DI wiring, and a client service exposed to application code. That is roughly a one-to-two day build. Treated as a checklist rather than a dependency, this package saves estimation time even though it saves no implementation time.

• Cross-language architecture bets. If the roadmap includes PHP services consuming topics produced by Java or .NET teams on ActiveMQ, this is evidence that the PHP side of that path exists — but also evidence that it must be owned in-house. It supports an informed "yes, with an owner named" or "no, standardize on AMQP" decision at the architecture level, not just the ticket level.

• A negative signal worth recording in the decision log. Its abandonment is a durable data point against building a product surface that depends on STOMP-over-stomp-php without internal ownership. Recorded once, it prevents the same evaluation from being redone by the next engineer who finds this package and thinks it looks convenient.

• Framework-mismatch precedent. The package is filed as a Laravel/PHP candidate but is structurally a Symfony2 bundle — it registers through Bundle classes and a DI extension that Laravel's kernel never invokes. That makes it a useful reference case for tightening intake criteria: "PHP package" is not a stack-fit signal, and a star count of 1 with 0 dependents is a disqualifier, not a caveat.

When to Consider This Package

Consider it only as reference material, never as a dependency. The narrow qualifying situation: you maintain a Symfony 2.x/3.x application (both EOL), you must speak STOMP to an existing ActiveMQ or Artemis broker, and you want a worked example of how to wire stomp-php into a container — connection factory, config tree, service definition. Even then, read it for the pattern and write your own.

Look elsewhere, or build, when:

• You are on Laravel. This is a Symfony bundle, not a Laravel package. There is no service provider, no publishable config, no facade. There is no adoption path short of a rewrite, which means you are really evaluating stomp-php and using this repository as documentation.

• You are on Symfony 5/6/7. The bundle predates Flex and autowiring; its configuration and registration model no longer fits the framework it was written for.

• You need maintenance, security patches, or PHP 8 support. No active maintainer, no dependent base to absorb breakage, no escalation path. For a production messaging path that is total vendor risk, not partial.

• Your broker speaks AMQP. Use php-amqplib or a maintained Laravel RabbitMQ queue driver and inherit retries, failed-job storage, and queue visibility instead of building them.

• You want framework-native messaging. Laravel's queue abstraction with a maintained transport, or Symfony Messenger, keeps you on supported, upgradeable ground.

• You need STOMP only for one or two publish/consume calls. Instantiate the client directly in a small service class. A wrapper adds a dependency without adding capability.

• No engineer can be named as owner. If the adapter will not have a named maintainer, the correct answer is AMQP or the framework-native queue, not STOMP.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. This is a Symfony2-era wrapper around stomp-php with one star, zero dependents, and no maintenance activity. It targets a framework line that has been end-of-life for years, and — critically for us — it is a Symfony bundle, not a Laravel package, so it cannot be installed into our application at all. The stack mismatch is structural, not cosmetic.

What it still buys us: a scoped estimate. The bundle does little beyond connection configuration and DI wiring, which tells us the genuine cost of an in-house equivalent is small — roughly one to two engineering days against stomp-php, or close to zero if we adopt the maintained enqueue/stomp client instead. We get the specification without taking the dependency.

Cost of the wrong choice. Pulling an unmaintained package into a production messaging path means we own its bugs, its PHP-version compatibility, and its security posture, with nobody upstream to escalate to. That is a permanent, unbounded maintenance line item acquired to save about a day of work — a bad trade at any scale.

Engineering guidance. If the business requirement is genuinely STOMP connectivity to a broker we already run for other teams, build a minimal adapter behind our own interface. That keeps the transport swappable, keeps the dependency footprint to one maintained library, and keeps ownership explicit. If the requirement is simply "run async jobs," use the framework-native queue and skip STOMP entirely.

Ask. Two decisions from this review: (1) confirm whether the target broker offers AMQP, which would make this whole thread moot; and (2) if STOMP is required, name the owning engineer before any code is written, because there is no upstream to fall back on.