Live Broadcast Bundle Laravel Package

Getting Started

Read this before anything else: martin1982/live-broadcast-bundle is a Symfony bundle, not a Laravel package. It ships a *Bundle class, Doctrine entities, Symfony DI wiring, Symfony forms/controllers and Twig templates. There is no service provider, no config/live-broadcast.php, no facade, and composer require into a Laravel app will drag in Symfony components you do not want. Your first decision is not "how do I install this" but "do I run it as a sidecar, or do I mine it for the domain model?"

Minimal steps:

1. git clone and read in this order — composer.json (PHP/Symfony constraints), src/ for the Bundle class and the entities/models, Resources/config/ for DI wiring and the config tree, Resources/config/routing* for the HTTP surface, Resources/views/ for the planner UI.
2. Identify the three seams that actually matter: the planned broadcast object (what is airing, when, on which channel/resource), the scheduler (turns plans into concrete slots and resolves overlaps/conflicts), and the platform distribution layer (Facebook, and whatever else it pushes to, via API calls to create/plan livestreams). The v7.0.5 release lands squarely on the third seam.
3. Only if you genuinely need it running: scaffold a matching Symfony app, register the bundle in config/bundles.php, import its routing, run Doctrine migrations, hit the planner route. Budget a day for version pinning.

First use case for a Laravel developer: treat it as a specification, not a dependency. Extract a broadcasts + broadcast_slots schema and a BroadcastScheduler service from it in a day, rather than fighting Symfony's container to get a bundle booting.

Implementation Patterns

Reference-port pattern (recommended default). Copy the entity fields into migrations, keep the semantics, drop the annotations. You keep the domain insight and none of the framework coupling.

Scheduler as a pure service. The valuable part is the scheduling logic — conflict detection, slot generation, recurrence. Port it to app/Services/BroadcastScheduler.php with repository interfaces injected, so it's testable without HTTP.

final class BroadcastScheduler
{
    public function __construct(private SlotRepository $slots) {}

    public function plan(BroadcastPlan $plan): Collection
    {
        // port of the bundle's slot-generation + overlap check
    }
}

Platform distribution as a driver. The bundle's Facebook API calls (the subject of v7.0.5) are your template for how a plan becomes a real livestream on an external platform. In Laravel, model this as an interface with per-platform drivers, not as a single hard-coded client:

interface LivestreamProvider
{
    public function schedule(BroadcastPlan $plan): ProviderStream;
    public function update(ProviderStream $stream, array $changes): void;
    public function cancel(ProviderStream $stream): void;
}

final class FacebookLivestreamProvider implements LivestreamProvider { /* ... */ }
final class YouTubeLivestreamProvider implements LivestreamProvider { /* ... */ }

Bind the concrete providers in a service provider and dispatch via a PublishLivestreamToProvider job. This is the seam most likely to break on you, so isolate it hardest.

Planner UI → Livewire. The bundle's Twig planner is a calendar/grid with create-edit-delete. That maps almost 1:1 onto a Livewire component with a wire:model per slot and optimistic validation; do not port the Symfony forms.

Recurring broadcasts → Laravel's scheduler + queued jobs. A weekly show is ->weeklyOn() dispatching a MaterializeBroadcastSlots job; the bundle's own cron/console command is the thing you replace, not reuse.

Overlap detection in Eloquent. The bundle's Doctrine DQL overlap queries become:

BroadcastSlot::where('channel_id', $id)
    ->where('starts_at', '<', $end)
    ->where('ends_at', '>', $start)
    ->exists();

Sidecar pattern (if you must run it as-is). Run the Symfony app alongside Laravel, expose the planner as JSON endpoints, call it over HTTP from a Laravel client. Only worth it if the bundle already does something you cannot reimplement — and now that it is actively maintained (v7.0.5 landed recently), "actively maintained" is a real argument in favour of the sidecar if you need the Facebook publishing path working now.

Pin behaviour with contract tests. Before porting, write a handful of tests against the Symfony service, then re-point them at your Laravel implementation. Scheduler code and platform API clients are where silent off-by-one, timezone, and "the API changed under us" bugs live.

Gotchas and Tips

• "Broadcast" means two different things. In Laravel it means websockets (ShouldBroadcast, Echo, Pusher). This package is about programming live shows/streams. Keep Illuminate\Broadcasting and App\Scheduling strictly separate or you will confuse every future reader.
• The package is maintained — but narrowly. Earlier notes flagged this as abandoned; v7.0.5 disproves that. The caveat is the release is a patch that only touches Facebook API calls. That means: bug/API-drift fixes land, new features are unlikely, and you should still pin a version and read changelogs, but you are not on dead code. Adjust the "fork and pin, expect nothing upstream" advice accordingly — fork only if you need to diverge, not because the project is stale.
• Facebook API coupling is your fragility surface. v7.0.5 is a reminder that external platform APIs version and deprecate on their own schedule. If you port the Facebook path, put the API version in config, wrap responses, and expect to touch it on the platform provider's cadence — not yours.
• Doctrine ≠ Eloquent. No unit of work, no flush(), no embeddables, no lazy persistent collections, no EntityManager::merge(). Any port that "follows the code closely" will carry over patterns that don't exist here.
• Don't carry the container across. Symfony services are private and autowired by default; the bundle's extension points are usually tagged services behind interfaces. Port the interface + strategies idea; rebuild the wiring in a service provider.
• Timezones are the real bug source. Planners store wall-clock times because humans think in them. Store UTC in the database plus an explicit timezone column, and convert only at the edges. Facebook's API expects a start time with a timezone — double-check what the bundle sends and what your port sends.
• Read DependencyInjection/Configuration.php before guessing config. Symfony bundles nest config under a root key (typically live_broadcast:) with a defined tree — anything not in that tree is silently rejected. Facebook credentials will live somewhere in this tree; grep the config tree for them.
• Namespace casing trips PSR-4. martin1982 in the package name vs Martin1982 in the PHP namespace; Composer will complain if you get it wrong when forking.
• Debugging the Symfony side: bin/console debug:container --tag=<tag>, debug:router, and debug:config live_broadcast tell you more in thirty seconds than an hour of reading source.
• Best extension points to steal: (1) the scheduler/collision-resolution strategy, and (2) the platform-provider abstraction implied by the Facebook call site. Define both as interfaces in Laravel, implement one concrete strategy each, and you get the bundle's flexibility without its framework.