Laravel Hooks Laravel Package

Product Decisions This Supports

• Build vs. buy for extensibility: Evaluate whether a Laravel-native hooks/processors abstraction replaces custom internal pipeline code. This release makes the wrapper a credible evaluation candidate because it now exposes the shared core beta API through familiar Laravel access paths — helper, facade, constructor injection, and hooks().
• Feature/roadmap bets: Supports discovery work for extensible content rendering and processing features: multi-step transformations, configurable rendering, tenant-specific processing, and plugin-like extension points.
• Architecture choices: Informs whether to standardize on facade/helper calls versus constructor injection, and whether singleton processor lifecycle fits the application’s request/job model.
• Prototype scope: Suitable for a time-boxed spike behind a feature flag, not for a production commitment while both wrapper and core remain in beta and v2 is intentionally breaking from v1.
• Migration planning: Signals a future v1-to-v2 migration cost; product should budget for it before adopting v1 or committing to the package long-term.

When to Consider This Package

• You need a hooks/processors abstraction in Laravel and want first-party-style integration: DI, facade, helper, and documented lifecycle behavior.
• You are comfortable depending on prerelease software: the wrapper requires magdicom/hooks ^2.0.0-beta.2, and v2 is explicitly breaking from v1.
• You have appetite for a spike and can isolate the dependency behind application-owned interfaces so a beta API change does not leak into product code.
• You want to validate the shared core API through Laravel access paths, including one-off processWith() / renderWith() calls.
• Look elsewhere if: you need stable, production-ready dependencies now; your needs are met by Laravel’s native events/listeners; you cannot absorb a v1-to-v2 migration; you require broad community support or long-term API stability guarantees; or you are unwilling to track two coupled beta packages.

How to Pitch It (Stakeholders)

• Executives: This is a low-cost evaluation of whether to buy into a hooks/processors layer instead of building pipeline plumbing ourselves. It is prerelease software, so the recommendation is a scoped spike with no production commitment. The upside is reduced custom code and a cleaner extension model; the risk is beta instability and a breaking v2 migration.
• Engineering: The wrapper tracks core magdicom/hooks beta.2 and exposes the Magdicom\Processors API through Laravel-native paths. Coverage now includes one-off processWith()/renderWith() calls via helper and facade, and docs cover constructor injection, hooks(), the optional facade, and singleton lifecycle. Adopt behind interfaces, pin beta versions, and expect breaking changes before stable.
• Product/PM: Treat v2 as a validation track, not a roadmap dependency. Define exit criteria for the spike, confirm whether Laravel events already solve the use case, and budget migration effort if the package becomes strategic after stable release.