Signal Slot Laravel Package

Technical Evaluation

• Architecture fit: SignalSlot is a generic observer/event-dispatch primitive from the retired Zeta Components (formerly eZ Components) stack. It is not a Laravel package — no service provider, no facade, no contract binding, no PSR-14 compliance. Laravel already ships a strictly superior first-party event system (Illuminate\Events\Dispatcher, listeners, subscribers, queued listeners, broadcasting). Introducing SignalSlot means running a second, competing event bus in the same process, which is the primary architectural objection and the main source of long-term drift.
• Integration feasibility: Low for greenfield work. The package predates modern Composer conventions (PSR-0 style autoloading, old PHP constraints), so composer require against Laravel 10/11 on PHP 8.2+ will likely fail on platform requirements or on runtime deprecations. Realistic adoption requires a fork with updated composer.json, PSR-4 autoloading, and PHP 8 cleanup.
• Technical risk: High and asymmetric. Upstream is dormant (Zeta Components was wound down circa 2014), with 3 stars, 0 dependents, no maintainers, no CI, and no security response channel. License is flagged NOASSERTION — historically Apache-2.0 across Zeta, which carries NOTICE-retention obligations; legal must confirm before any distribution. Supply-chain and abandonment risk vastly outweigh the value of a library whose functional surface is a dozen small classes.
• Key questions:
  1. Which concrete legacy component actually emits or consumes Signals — is this a genuine bridge requirement or exploratory interest?
  2. What behavior does Laravel's dispatcher fail to provide that SignalSlot does?
  3. Can legal clear NOASSERTION, and is the upstream NOTICE file intact?
  4. Who owns the fork and its patch cadence if we take one?
  5. Does this clear our OSS intake policy for dormant, zero-adoption dependencies?

TPM position: do not adopt for new development. Leverage only as a narrow anti-corruption layer in front of legacy eZ/Zeta code, with a documented retirement date.

Integration Approach

• Stack fit: Poor as a primary event layer; acceptable only as a boundary shim. Target state remains Laravel's dispatcher — new application code must never import ezcSignalSlot* namespaces directly.
• Migration path: If legacy code already uses SignalSlot, wrap it behind a first-party EventBus interface (or an implementation of Illuminate\Contracts\Events\Dispatcher that delegates to SignalSlot). Migrate handlers in waves: mirror each signal to a Laravel event, dual-run both paths in staging, then delete the legacy signal once the last slot is ported. If greenfield, skip the dependency entirely and reimplement the few semantics needed as Laravel listeners — that is a days-scale task, not a months-scale one.
• Compatibility: Verify require.php, autoload type, and namespace casing in composer.json. Expect to vendor a fork with a pinned tag; never depend on dev-master from the upstream repository. Confirm no collision with symfony/event-dispatcher, which Laravel pulls transitively and which exposes similar concepts under different semantics.
• Sequencing: (1) license/legal clearance → (2) inventory of Signal/Slot usage across the legacy surface → (3) fork and modernize (composer, PSR-4, PHP 8, static analysis) → (4) adapter behind a first-party interface → (5) dual-run and observe → (6) decommission. Treat this as a maintenance-blocker remediation, not a feature enabler; it should not outrank roadmap work.

Operational Impact

• Maintenance: Effectively zero upstream. Any fork becomes wholly ours — PHP upgrades, security patches, and bug fixes included — for a library small enough that reimplementation is cheaper than stewardship. Budget a one-time port and a retirement milestone, not recurring dependency management.
• Support: No vendor, no community, no CVE feed. Incident response depends entirely on internal knowledge. Acceptable for a scoped adapter; unacceptable for a core event bus.
• Scaling: In-process and synchronous. Fan-out happens on the calling thread with no queueing, retry, persistence, backpressure, or ordering guarantees. Suitable for a handful of in-request hooks; unsuitable for anything requiring durability or cross-service delivery — route those through Laravel queues or a broker. Watch for accidental O(n²) fan-out and slots that retain references across long-lived workers.
• Failure modes: Slot exceptions propagate into the emitting code path unless the caller isolates them; slot ordering is implicit and silently breaks on refactor; there is no dead-letter or replay; per-request registration in queue workers leaks connections. These failures surface in production telemetry, not in tests.
• Ramp-up: The API is learnable in under an hour, which is precisely the problem — engineers learn it, then ask why it exists alongside Laravel's dispatcher. Direct ramp-up cost is low; the cognitive load and code-review friction of a second event model is not. That cost is the reason to confine adoption to a documented boundary layer with an explicit exit plan.

Recommendation: leverage as a thin, forked compatibility shim only where legacy Signals already exist, gated on license clearance and an owner; otherwise standardize on Laravel's native event system and close the evaluation.