Turbo Toast Bundle Laravel Package

Technical Evaluation

Architecture fit. turbo-toast-bundle is a Symfony bundle, not a Laravel package. It sits on top of Symfony UX Turbo (symfony/ux-turbo + symfony/stimulus-bundle) and exposes server-driven toast notifications to a Hotwire/Turbo front end. If our reference stack is Laravel, there is no drop-in path: Laravel has no Symfony bundle kernel, no Stimulus importmap convention, and no UX Turbo integration out of the box. The asset-side logic (a Stimulus controller listening for Turbo Stream events) is conceptually portable, but the PHP side almost certainly depends on Twig and the Symfony DI container. The practical architecture fit is therefore strong for Symfony/Turbo applications, poor for Laravel applications, and the framing of this package in our portfolio should be corrected before any planning assumption depends on it.

Integration feasibility. Mechanically trivial in a Symfony app: composer require, enable the bundle, add the Stimulus controller to the asset pipeline, render a toast from a controller or Turbo Stream response. The v0.4.0 change does not alter that path at all — no config keys, no templates, no Stimulus identifiers, no public API touched. The only functional delta is a widened Composer constraint.

Technical risk. Low, and lower than v0.3.0. The release removes a hard installation blocker (UX 3 apps previously could not resolve the bundle). Two residual risks remain, neither introduced by this release:

1. Pre-1.0 versioning. At 0.x there is no backward-compatibility guarantee. A future 0.5.0 could rename a Stimulus identifier or a Twig template block and be within its rights.
2. PHP 8.4 coupling on the UX 3 path. UX 3 requires PHP >= 8.4; on PHP 8.3 Composer silently resolves UX 2. This means the UX major we actually run is a function of our PHP version, not a deliberate choice, unless we pin it. That is a configuration hazard more than a defect.

Encouragingly, the maintainer added a CI matrix that actively fails if a job resolves to the wrong UX major — that is a maturity signal (they are testing the compatibility claim rather than asserting it) and it partially offsets the bus-factor concern of a single-maintainer package.

Key questions.

• Is any part of this bundle reusable outside Symfony — specifically the JS/Stimulus controller and the Turbo Stream payload shape — or is the PHP layer inseparable?
• What is the license, and is there a published security policy?
• Who is the maintainer, what is the release cadence, and is there a stated 1.0 timeline?
• Does the bundle pin to Twig, and to which Twig major?
• Are we standardising on Symfony UX at all, or is this a one-off evaluation?

Integration Approach

Stack fit. Only pursue if we have a Symfony application on UX Turbo (or are about to build one). For a Laravel codebase, treat this as a reference implementation, not a dependency: read the Stimulus controller and the Turbo Stream contract, reimplement the ~50 lines in our own front end, and drop the PHP package.

Migration path. Upgrading an existing v0.3.0 install is a no-op — the changelog explicitly states "Nothing to do," and the bundle does not pull UX 3 in by itself; the application's own constraints decide the major. For a new install, the install is the migration.

Compatibility. Two supported lanes: PHP 8.3 + UX 2, and PHP 8.4 + UX 3. Both are tested in CI, with UX 3 exercised from 3.0.0 through latest. Our lane should be chosen explicitly and pinned in composer.json so an unrelated PHP upgrade in CI or on a base image doesn't silently move us between UX majors.

Sequencing.

1. Confirm the framework question above — this gates everything else.
2. If Symfony: pin the UX major explicitly, install behind a feature flag, and wire one toast call site end-to-end before rolling out broadly.
3. If Laravel: scope a small port of the client-side controller instead, and record that decision so this package isn't re-evaluated as a candidate next quarter.

Operational Impact

Maintenance. Near-zero surface area. No config, no schema, no background workers, no migrations. The main ongoing cost is watching a 0.x package for breaking changes, which is a periodic version-pin review rather than active maintenance.

Support. Single-maintainer, small-community project. There is no vendor to escalate to and no paid support tier. Internal ownership must therefore include "we can fork or vendor the controller if upstream stalls" — which is realistic here given the small code surface.

Scaling. The workload is toast rendering on the request/response path; it does not add queries, queues, or external service calls. Scaling characteristics are inherited entirely from the host application. No new bottleneck.

Failure modes.

• Silent UX major drift — a base image moving to PHP 8.4 flips Composer to UX 3 without anyone choosing it. Mitigate with an explicit constraint and a CI assertion on the resolved version (mirroring what upstream now does).
• Asset pipeline breakage — Stimulus controller not registered, or the importmap misconfigured; toasts fail silently rather than erroring loudly. Worth a smoke test.
• Upstream abandonment — mitigated by the code being small enough to vendor.
• Unpinned 0.x upgrade — a composer update picking up a future breaking 0.5.0. Mitigate with a caret constraint at the minor level.

Ramp-up. Under a day for a Symfony developer familiar with Turbo: install, register the controller, emit one toast, done. For a Laravel team, the ramp-up is really "learn Turbo Streams," which is a multi-day investment and should be justified by more than this bundle.