Hook Bundle Laravel Package

Technical Evaluation

Architecture fit

• Stack mismatch remains the headline finding, unchanged by this release. scylabs/hook-bundle is a Symfony bundle, not a Laravel package. It ships a ScyLabsHookBundle class, a DependencyInjection/ extension, and service-container wiring that only resolves inside a Symfony Kernel. Composer will install it into a Laravel app, but nothing registers: no service provider, no facade, no auto-discovery entry. In a Laravel codebase this is dead weight without a hand-written adapter or a fork. v1.0.6 does not change this — "Fixes Container injection" is a fix to the Symfony DI extension, which is precisely the machinery Laravel does not have.
• If the target stack is Symfony, the fit is acceptable but era-bound. The bundle's model — named template "hooks" (injection points) exposed to a functional API, backed by bundle config — maps onto Symfony's existing EventDispatcher and Twig extension mechanisms. It is a convention layer, not novel infrastructure.
• Conceptual overlap. The value proposition (injectable template fragments at named positions) is already served in modern Symfony by Twig runtime extensions, EventDispatcher subscribers, or a block/renderer component. Differentiation is ergonomics, not capability.

Integration feasibility

• Low effort to install, high effort to operate. composer require plus bundle registration is minutes; establishing that it works against your PHP and Twig versions is the real cost.
• What changed: v1.0.6 is a patch release addressing container injection — the DI extension path that must work for the bundle to boot at all. That is a favourable signal: the maintainer is not entirely absent, and the defect being fixed is in the exact component that would block container registration on a modern Symfony kernel.
• What did not change: compatibility remains the blocker. There is no evidence in the release note of widened php/symfony/*/twig/* constraints, no changelog, no stated supported-version matrix, and no CI/test artifacts. A single-line note ("Fixes Container injection") does not tell us which Symfony versions it fixes injection for. Do not infer Symfony 6/7 support from a patch version bump.
• Still no adapter path for Laravel that is worth building. Wrapping a Symfony container extension into Laravel's service container means reimplementing the template-hook semantics in the Blade/view layer anyway. That is a rewrite, not an integration.

Technical risk

• Signal inconsistency to flag, partially softened. The rubric shows score: 0.035 against opportunity: 8.68. The near-zero adoption score is now slightly stale — the artifact has demonstrable, if minimal, maintenance activity. Treat opportunity as a concept score regardless; v1.0.6 does not create an ecosystem, dependents, or documentation.
• Still no test/CI evidence and no dependents. We would be among the first production consumers. There is no community precedent to borrow confidence from.
• Interpretation caution: "Fixes Container injection" is ambiguous. It may mean (a) the bundle now registers correctly on modern Symfony containers — materially good, or (b) a narrow fix for a specific DI edge case, leaving version constraints untouched. This distinction is the single highest-value thing to resolve before any decision.

Key questions for the team

1. Is the target application Symfony or Laravel? If Laravel, this evaluation terminates — v1.0.6 does not alter that verdict.
2. If Symfony: does v1.0.6 install without --ignore-platform-reqs? The release note implies container work, not constraint work — verify rather than assume.
3. Does the injection fix apply to our Symfony major, or to the 4.x/5.x line the bundle was written for? Ask upstream directly; a responsive maintainer is now a plausible assumption.
4. What is the cost of reproducing the hook semantics natively (Twig extension + event subscriber, ~1–2 engineer-days) versus forking and maintaining this bundle (~ongoing)?
5. Do we need the template layer, or only the hook dispatch layer? If the latter, EventDispatcher already ships it.
6. Who owns the fork if we adopt? Name a person before adoption, not after.

Recommendation (revised): still do not adopt as a direct production dependency, but downgrade from "do not adopt" to "do not adopt without re-spiking." The v1.0.6 container-injection fix makes the one-day spike materially more likely to pass than previously assessed. Run the spike against v1.0.6 specifically; if it boots cleanly on our Symfony/Twig versions without constraint hacks, the case for forking narrows to a routine internal-maintenance decision rather than a rescue. If it does not, fall back to the original position: mine it as a reference implementation and reimplement the ~200 lines natively.

Integration Approach

Stack fit

• Laravel target: no fit, unchanged. No service provider, no config publish tag, no Blade integration. Do not plan an integration; plan a reimplementation of the pattern using Blade components/slots plus Laravel's event system if the concept is desired.
• Symfony target: conditional fit, mildly improved. Previously scoped to Symfony 4.x/5.x + Twig 2.x. v1.0.6 indicates active work on the DI extension, which is the gate for modern-kernel registration — but the release note does not assert a supported version range. Treat modern-Symfony support as unverified, not as claimed.
• Concept fit is the durable asset. "Named hook points in templates + functional registration" is a legitimate internal pattern in either framework. Adopt the pattern, not the artifact — unless the spike on v1.0.6 clears cleanly.

Migration path

1. Spike (≤1 day, now with a higher prior of success): install v1.0.6 into a throwaway Symfony app pinned to our production version. Record: (a) does Composer resolve without --ignore-platform-reqs; (b) does the container extension register; (c) does hook rendering work under our Twig version. The container-injection fix targets (b) directly — this is the specific thing it may have unblocked.
2. If the spike passes: fork to an internal namespace, pin constraints explicitly, add a test suite covering hook registration, ordering, and template rendering, and publish to a private registry. Even in the good case the fork is warranted — we still need a maintenance owner and a CI matrix.
3. If the spike fails: reimplement. Deliver an internal package — HookRegistry service, hook() Twig function, functional registration API mirroring the bundle's surface — behind our own namespace and versioning. Estimated 1–3 engineer-days including tests.
4. Consumer migration: if existing templates already use hook syntax, write a thin compatibility layer so view files do not need touching during the transition.

Compatibility

• Pin explicitly and document: PHP minor, Symfony major, Twig major. Do not allow floating constraints on a lightly-maintained dependency.
• Record the v1.0.6 baseline in the spike notes so a future regression can be bisected against a known-good point.
• Verify no reliance on removed Symfony components (templating, older HttpKernel event names). These are common failure points for 2020-era bundles and are not addressed by a container-injection fix.

Sequencing

• Week 1: stack decision (Laravel vs Symfony) → v1.0.6-specific spike → go/no-go memo. Optionally file one upstream question about supported Symfony versions; a fast, substantive reply is itself useful evidence about maintainer health.
• Week 2: if no-go, ship internal replacement package behind a feature flag; if go, fork + test harness + private registry entry.
• Week 3: migrate one low-traffic template surface, observe, then widen.
• Do not sequence this behind a release-critical path. It is a convenience layer; treat it as such.

Operational Impact

Maintenance

• Revised posture: "lightly maintained," not "dormant." v1.0.6 shows the maintainer is reachable and shipping. That reduces — but does not eliminate — the risk that we inherit a dead codebase. The practical distinction: an abandoned dependency means we own unfixable code; a lightly-maintained one means we own code we may have to fix ourselves on someone else's schedule.
• Any adoption still implies we own the constraint set and the security posture. Budget this explicitly. A single patch release is not a release cadence; if no further releases follow within a reasonable window, revert the risk rating to High.
• The fork burden is small (the package is thin) but non-zero: PHP/Symfony/Twig upgrade cycles will each require a compatibility pass we author ourselves.
• If reimplemented natively, maintenance collapses to our own code under our own release cadence — still the preferred outcome absent a clean spike.

Support

• No vendor, no SLA, no security disclosure channel. Escalation path must be "the engineer who owns the fork," a bus-factor-1 arrangement. v1.0.6 slightly improves the odds that an upstream question gets answered, but does not create a support relationship.
• Knowledge transfer is entirely from source reading. No documentation ecosystem, no tutorials, effectively no community to consult (0 dependents).

Scaling

• Hook dispatch is in-process and synchronous; overhead is proportional to registered handlers per hook point and is negligible at typical template counts.
• The real scaling constraint is template cache invalidation. Ensure the fork/native implementation participates correctly in Twig's cache warmup and that hook registration is compile-time deterministic (container compile pass), not runtime-mutable — otherwise you get per-request cache misses.
• New consideration given v1.0.6: because the fix touches container injection, validate cache warmup and container compile under both cold and warm cache in the spike. Compile-time fixes can shift when the cache must be rebuilt.
• No horizontal scaling concerns; it is stateless PHP.

Failure modes

• The dominant operational hazard remains silent degradation: missing hooks produce blank regions rather than errors, surfacing as a visual defect in production rather than a failing build. Note the asymmetry introduced by v1.0.6 — the fixed class of bug fails loudly at boot, while the unfixed class still fails quietly at render.

Ramp-up

• Concept ramp-up is low — the template-hook model is intuitive and matches patterns engineers already know from CMS templating. Under a day for a mid-level engineer.
• Artifact ramp-up is misleadingly low: installing is trivial, but understanding its failure modes requires reading the source, because there is no documentation and no community memory.
• Onboarding cost is highest for the fork owner, who must answer "what breaks on the next Symfony upgrade" without upstream help. v1.0.6 makes that conversation marginally more tractable — a maintainer who responds is worth one question — but it does not remove the need to name the person.

Bottom line for the TPM: the release is a genuine but small positive signal — a maintainer is alive, and the fix targets the exact gate that blocked modern-Symfony registration. It does not fix the Laravel stack mismatch, does not evidence constraint widening, and does not constitute a support commitment. Recommend re-running the one-day spike specifically on v1.0.6, with the prior now leaning toward "fork and own it" rather than "reimplement from scratch." Close the dependency question either way within two weeks; do not let a promising patch release leave this in indefinite evaluation.