Bridge Bundle Laravel Package

Getting Started

This is not a standalone library — it is a Symfony bundle that only makes sense inside a Superdesk Web Publisher (SWP) application. Installing it into a bare app, or a Laravel app, gives you service definitions and a DI extension that reference services that don't exist.

Minimal steps:

1. Require it into an existing SWP installation: composer require swp/bridge-bundle. Check composer.json for the symfony/* constraints it expects before you do — the 2018 tag pins you to Symfony 2.8/3.x-era APIs.
2. Register the bundle (SWP\Bundle\BridgeBundle\SWPBridgeBundle) in app/AppKernel.php (legacy) or config/bundles.php.
3. Check the bundle's DependencyInjection/Configuration.php and dump the reference (bin/console config:dump-reference <alias>) to see what is actually configurable — that config tree is the real public API of this package.
4. Look first at, in this order: DependencyInjection/ (service wiring and config), Resources/config/ (services + routing), then Command/, Consumer/, or MessageHandler/ for the moving parts that do the work.
5. First real use case: getting editorial content from an external source system into SWP. In practice you configure a transport, publish a message in the shape the bundle's handler expects, run the consumer, and watch an SWP article appear.

Expect your integration work to be ~80% YAML configuration and message contract, ~20% PHP.

Implementation Patterns

Configure, don't call. The bundle is designed to be wired up and left running; your application code rarely invokes it directly. Treat the bundle's config tree and the message payload shape as the integration surface.

Producer/consumer split. The typical workflow is: your source system (Superdesk, a CMS export, a webhook receiver) publishes a message to a queue; the bundle's consumer picks it up and materialises content in SWP. Keep the producer and consumer deployed independently and let the queue absorb downtime.

Align payloads with the handler. Read the message handler's type hints and required fields before writing a producer. Version your payloads from day one ({"version": 1, ...}) — you will not get a schema migration path from a package that hasn't shipped since 2018.

Override services instead of forking. Because the repo is read-only, use Symfony's own extension points: a compiler pass, a services.yaml redefinition, or a decorator around the bundle's handler. This survives composer update; a vendor patch does not.

Run workers properly. Put the consumer command under supervisor or systemd with autorestart, log to a file, and restart workers on every deploy. A silently dead consumer is the number-one failure mode here.

Test at the kernel level. Boot the kernel in a functional test, point the transport at an in-memory/sync queue, dispatch a fixture message, and assert the resulting content. Unit-testing this bundle in isolation mostly tests Symfony, not your integration.

Gotchas and Tips

• Read-only subtree split. This repository is generated from the SuperdeskWebPublisher monorepo. Issues and PRs here are pointless — go upstream. Releases mirror the monorepo and can lag it.
• Last release mid-2018. Assume legacy Symfony idioms: container-aware commands, possibly Swiftmailer, no attributes. Porting to Symfony 5+/6+ will be real work, not a composer update. Plan to run it in an old container or alongside a legacy app.
• AGPL-3.0. Network copyleft: if you modify it and serve it over the network, you must offer the modified source. Get legal sign-off before embedding in a commercial SaaS.
• Zero stars, zero dependents. There is no community, no Stack Overflow coverage, no blog posts. Your debugging tools are the source, the monorepo, and bin/console debug:container / debug:event-dispatcher.
• Composer quirks. Subtree splits frequently carry a composer.json that differs from the monorepo (branch aliases, replace entries). Verify you're pulling the tag you think you are, and check whether the monorepo's split is stale relative to master.
• Queue debugging. Turn Monolog up on the consumer process, and inspect the dead-letter queue first when messages "disappear." Most integration bugs are serialization/fixture mismatches, not bundle bugs.
• Extension points, ranked: bundle config → service override/decorator → event subscriber → message contract change. Patching vendor/ is never one of them.