Laravel Hooks Laravel Package

Technical Evaluation

Architecture fit. Laravel Hooks is a thin Laravel wrapper over the magdicom/hooks core package. v2.0.0-beta.3 exposes the core beta.2 API through Laravel-native access paths: a helper, an optional facade, constructor injection, a hooks() accessor, and documented singleton lifecycle. The design intent is a lightweight extension/hook layer integrated into the service container rather than a standalone subsystem. This fits applications that want named extension points resolved through the container, and it fits least well in codebases already standardized on Laravel's event/dispatcher or pipeline primitives, where a second extensibility mechanism adds conceptual overlap.

Integration feasibility. Installation is a single Composer operation, but requires explicit beta stability flags on two packages simultaneously:

composer require magdicom/laravel-hooks:"^2.0@beta" magdicom/hooks:"^2.0@beta"

This is feasible for a spike or a pre-production branch. It is not feasible as a production dependency without an explicit risk acceptance, because both the wrapper and its core are prerelease and the wrapper's constraint is pinned to a specific core beta line.

Technical risk.

• Two-package lockstep. The wrapper requires magdicom/hooks ^2.0.0-beta.2. Any core beta.3+ bump, or a core stable release that changes the constraint, forces a coordinated wrapper upgrade. Dependency resolution failures are the most likely day-one integration problem.
• Pre-1.0 stability semantics. Beta releases may change signatures, namespaces, and container bindings without deprecation cycles. The Magdicom\Processors namespace move in this release is exactly the class of change that silently breaks imports.
• Intentional break from v1. v2 is explicitly breaking from v1, and the notes do not describe the delta. Any existing v1 usage is a rewrite of integration points, not an upgrade.
• Singleton lifecycle. A singleton-scoped hook registry in a long-lived process (Octane, queue workers, Swoole) is a shared-state surface. Registration order and mutation timing become correctness concerns, not style concerns.
• No wrapper API surface change is a positive signal for churn, but it also means this release carries no new functional capability to justify risk on its own.

Key questions.

1. What specifically breaks between v1 and v2, and is there a migration guide or upgrade test suite?
2. What are the supported PHP and Laravel version ranges, and is illuminate/support constrained narrowly enough to avoid conflicts in a mature dependency graph?
3. Is the singleton lifecycle container-scoped or application-scoped, and is it documented as safe under Octane and queue workers?
4. What is the stable v2.0.0 timeline, and is the beta window expected to be weeks or months?
5. Who maintains the core and wrapper, and what is the bus factor?
6. Does the integration coverage for processWith() / renderWith() via helper and facade extend to the remaining access paths (constructor injection, hooks()), or is coverage partial?
7. What is the per-request cost of resolving and dispatching a hook, and is there a caching story?

Integration Approach

Stack fit. Appropriate for Laravel applications that want container-resolved extension points with a small API. Poor fit for non-Laravel PHP services (the wrapper is the value; the core alone would be the dependency) and for teams unwilling to run prerelease code. No signal of framework-version breadth, so assume a narrow, recent-Laravel target until confirmed.

Migration path. Treat v1 → v2 as a greenfield integration rather than an upgrade. Recommended path: inventory every v1 touchpoint (helper calls, facade calls, injected contracts, registered hooks), map each to the v2 access path, and confirm the Magdicom\Processors namespace is reflected in all imports. Do not run v1 and v2 side by side in one application; the container bindings will collide.

Compatibility. The binding constraint is a two-package beta requirement. Before committing, run a composer require --dry-run against the real application lockfile to surface conflicts with anything else that depends on magdicom/hooks or on the same Laravel major. Version 2's break from v1 means any transitive dependency still on v1 pins the whole graph.

Sequencing.

1. Confirm stable-release timeline and v1→v2 delta. If unknown, stop here and stage the work.
2. Spike in a scratch branch against a representative slice of the app, not a hello-world controller — exercise constructor injection, hooks(), helper, and facade in the same container.
3. Build a thin internal adapter around the hook registry so the core namespace and signatures appear in exactly one place. This is the single highest-value mitigation given prerelease churn.
4. Validate under the production runtime shape: Octane or queue workers if used, plus a repeated-request test to detect singleton state leakage.
5. Hold production adoption until v2 stable, then re-pin and re-run the adapter's test suite unchanged.

Operational Impact

Maintenance. Ongoing cost is tracking two packages with coupled version constraints and a demonstrated willingness to make breaking changes inside a beta line. Budget for a re-review at each core or wrapper release until v2 stabilizes, then a lower steady state. The internal adapter from the sequencing step converts each future core bump from an application-wide search-and-replace into a one-file change.

Support. A published documentation site and documented injection/lifecycle patterns are meaningful positives — most packages at this maturity stage have neither. The countervailing risk is concentration: a two-package, apparently small-maintainer ecosystem with no stated support commitment. Teams should expect self-support and should not depend on upstream responsiveness for production incidents.

Scaling. Hook resolution is container-mediated and expected to be cheap per dispatch, but this is unverified — no benchmarks accompany the release. The scalability question that matters more is state: singleton-scoped registration under concurrent or long-lived workers. Confirm registry state is reset or immutable per request before scaling out horizontally.

Failure modes. Watch for:

• Composer resolution failure from the dual beta constraint, most likely at first install and at every dependency refresh.
• Namespace drift after the Magdicom\Processors move, producing class-not-found at boot rather than at call time.
• Container binding conflicts when v1 and v2 artifacts coexist in the dependency graph.
• Silent no-ops where a hook is dispatched but nothing is registered — behavior that passes tests and fails in production.
• Cross-request state bleed under Octane or queue workers.
• Facade accessor mismatch after the optional-facade changes.

Ramp-up. Moderate for a Laravel developer: the helper and constructor injection paths are idiomatic and the documentation lowers the initial curve to hours. The real ramp-up cost is concentrated in operations and release engineering, not application code — specifically, teaching the team to treat the beta pin as a deliberate, reviewed decision rather than a version string, and to route all core interaction through the internal adapter so future breakage stays contained.