- How do I install magdicom/laravel-hooks in Laravel?
- Install it with Composer in a single step, but you must opt into beta stability for both the wrapper and its core package: composer require magdicom/laravel-hooks:"^2.0@beta" magdicom/hooks:"^2.0@beta". The wrapper is a thin layer over magdicom/hooks, so both packages arrive together and their version constraints move in lockstep. Expect to add explicit @beta flags because neither package is a stable release yet.
- Which Laravel and PHP versions does laravel-hooks support?
- The package documentation does not publish an explicit version matrix, so treat it as targeting recent Laravel releases until the maintainer confirms otherwise. Because it is a Laravel wrapper it depends on illuminate/support, and that constraint is the thing most likely to conflict inside a mature dependency graph. Run composer why-not illuminate/support in your application before adopting it.
- Is laravel-hooks stable enough for production?
- Not without an explicit risk acceptance. The current release is 2.0.0-beta.3 and it depends on a specific beta line of magdicom/hooks, so both packages are prerelease and may change signatures, namespaces, or container bindings without deprecation cycles. It is reasonable for a spike or a pre-production branch, but a production dependency means accepting lockstep upgrades and possible breaking changes. No stable 2.0.0 date is published in the available material.
- What is the difference between actions and filters in laravel-hooks?
- Actions are named extension points you run for side effects, while filters receive a value, let registered callbacks modify it, and return the result. The package exposes processWith() and renderWith() style entry points for running hooks through the helper and the facade. Both are resolved through the Laravel container rather than being a standalone subsystem.
- Should I use the hooks() helper or the Hooks facade?
- Both are Laravel-native access paths to the same underlying hook registry, so the choice is mostly stylistic. The facade is optional and gives you static-looking calls that are easy to swap in tests, while the hooks() helper is a global function that is convenient inside views and package bootstrapping. Constructor injection is the third access path and is usually the cleanest option for testable classes.
- Does laravel-hooks support dependency injection and container resolution?
- Yes. The package is built around resolving the hook registry through Laravel's service container, so you can constructor-inject it into your own classes instead of reaching for the helper. The documentation notes that integration coverage for processWith() and renderWith() via the helper and facade may not extend to every access path, so verify constructor injection and hooks() behavior for your use case. That partial coverage is worth a quick test in your own app.
- Is laravel-hooks safe with Laravel Octane and queue workers?
- Be cautious. The hook registry is documented as a singleton, and a singleton in a long-lived process such as Octane, Swoole, or a queue worker is shared state across requests and jobs. Registration order and the timing of mutations become correctness concerns rather than style concerns, so register hooks during application boot rather than per request. Confirm whether the binding is container-scoped or application-scoped before relying on it in a long-lived worker.
- How do I migrate from laravel-hooks v1 to v2?
- Treat it as a greenfield integration rather than an upgrade, because v2 is explicitly breaking and the release notes do not describe the delta. Inventory every v1 touchpoint, including helper calls, facade calls, injected contracts, and registered hooks, and map each one to its v2 access path. Update imports for the Magdicom\Processors namespace move, which is exactly the kind of change that silently breaks autoloading. Do not run v1 and v2 side by side in one application, since the container bindings will collide.
- What are the alternatives to laravel-hooks?
- Laravel's built-in event dispatcher and pipeline primitives cover many of the same extension use cases without adding a second extensibility mechanism, which is why teams already standardized on events may see conceptual overlap. If you only need the hook primitives and not the Laravel integration, magdicom/hooks is the real dependency and the wrapper is the value you would be dropping. Choose laravel-hooks when you specifically want named, container-resolved extension points with a small API surface.
- Is laravel-hooks actively maintained, and when will v2.0.0 be stable?
- The available material gives no stable 2.0.0 timeline, so ask the maintainer whether the beta window is expected to be weeks or months. Maintenance is a real consideration because the wrapper and core must move in lockstep, and the bus factor across both packages is undocumented. Before committing, check the repository commit history and issue responsiveness on GitHub.