Voyager Hooks Laravel Package

Product Decisions This Supports

• Extend the Voyager admin panel without forking it. This package is the difference between "we patch vendor/ and rebase on every upgrade" and "we register hooks and keep the core clean." For a team running Voyager 1.x, that is a direct reduction in maintenance cost and upgrade risk on an internal, non-differentiating surface.
• Build vs. buy (buy-in-micro). The capability — a hook registry plus a Blade directive sprinkled through Voyager's admin views — is small enough that a mid-level engineer could reimplement it in under a day. The decision to buy here is really a decision to accept the package's naming conventions and file layout as your extension contract, in exchange for not maintaining that plumbing yourself. Weigh that against a one-day build that you fully control and can keep alive.
• Roadmap fork: "invest in Voyager" vs. "migrate the admin." Adopting this package is a de facto commitment to Voyager's lifecycle. It should only be approved alongside an explicit answer to "when do we move to Filament / Nova / Backpack?" The package is a bridge, not a destination — treat every hook written as migration debt to be inventoried.
• Use cases it unlocks cheaply:
  • Dashboard and layout injections — analytics tags, consent banners, support-widget embeds, "environment: staging" ribbons.
  • Model-level admin customization — extra form fields, contextual help text, read-only computed panels, approval/review buttons on browse pages.
  • Workflow affordances — bulk actions, status transitions, and audit annotations surfaced in the admin without touching core views.
  • Per-tenant or per-role UI variations for internal CRMs and back-office tools where the admin is a cost center, not a product.
• Scoping signal for stakeholder conversations. 204 stars, a single maintainer ecosystem (larapack), last release March 2020, and a low opportunity score (~1.5) all say the same thing: this is a niche utility in a shrinking ecosystem. That doesn't disqualify it for a legacy Voyager install, but it disqualifies it anywhere the admin panel is customer-facing or revenue-adjacent.
• Risk budgeting, not feature budgeting. The real cost line isn't the license (MIT, zero) — it's that we inherit an unmaintained dependency on top of an unmaintained framework. Approve it with a named owner, a pinned version, a vendored fork path, and a scheduled re-evaluation at the next Laravel major upgrade.

When to Consider This Package

Consider it when:

• You are already committed to Voyager 1.x in production and the admin is internal, low-traffic, or a back-office cost center. The migration cost off Voyager dominates any other consideration.
• You need UI-level extension points — inject markup, fields, buttons, or scripts into Voyager's admin views — and the alternative is editing files under vendor/ or maintaining a fork.
• Your team is small and time-boxed, and the cheapest correct move is to ship the admin customization this sprint rather than rebuild it.
• You have engineering capacity to own it: pin the version, vendor or fork it under MIT, add an integration test around each hook you register, and document the hook inventory.
• You need a temporary bridge while a replacement admin (Filament, Nova, Backpack, or a bespoke Livewire surface) is scoped and funded.

Look elsewhere when:

• Greenfield or new admin builds. Do not start on Voyager in 2024+ to gain access to this package. Choose a maintained admin framework and get extension points as a first-class feature.
• You need a supported dependency. No release since March 2020, no vendor SLA, single-maintainer ecosystem. Any compliance regime requiring maintained dependencies or CVE response will fail here.
• The admin is customer-facing or revenue-adjacent. Debugging indirection through a hook layer you didn't write, on a framework that isn't patched, is the wrong risk profile for anything external.
• You are actively migrating off Voyager. Adding hooks only deepens the coupling you're trying to unwind.
• Your needs exceed injection. Hooks add markup at predefined points; they don't give you new business logic, authorization, or data-model capability. If you need that, you need a fork or a different framework — and the package becomes a half-measure.

Adoption checklist (gate before merge): confirm Voyager and Laravel version compatibility in a staging environment; verify each hook point you need actually exists in your Voyager version; confirm the license and your ability to fork; assign an owner; set a review date.

How to Pitch It (Stakeholders)

For executives: We have a small, free (MIT) utility that lets us customize our Voyager admin panel without forking the framework. The business value is straightforward: less engineering time spent re-applying patches to vendor code on every upgrade, and faster turnaround on internal admin requests — extra fields, approval buttons, analytics tags — without touching the core. There is no license cost and no procurement cycle. The important caveat is lifecycle: this package has not shipped a release since 2020, and neither has Voyager. That makes it a bridge, not a foundation. I recommend approving it only as a time-boxed extension layer with a named owner, a pinned version, and a funded plan to move the admin onto a maintained framework. Every customization we build on it should be logged as migration debt so the eventual move isn't a surprise.

For engineering: The value proposition is narrow and honest — a hook registry plus Blade-level injection points through Voyager's admin views, so you stop patching files under vendor/. It's small surface area and easy to read in an afternoon. But we own it from day one: pin the version, vendor or fork it (MIT permits it), wrap each hook registration in a test, and keep an inventory of every hook point we depend on. If a hook we need doesn't exist in our Voyager version, treat that as a fork decision, not a workaround. And do not let hook-based customization become the reason we defer the framework migration — the dependency graph here only gets harder to unwind the longer we stay.