Hookshelper Laravel Package

Product Decisions This Supports

A small, concrete build-vs-buy call on developer tooling. This package answers a narrow question: "which Filament render hooks exist on this page, and where do they render?" It does that by injecting a toggle button into the panel that labels the available hooks in-place. That is a debugging/visualization aid for one framework's extension seam — not a runtime feature, not a user-facing capability. Treat the decision it informs as a composer require-dev line item, not a roadmap bet.

Decisions it genuinely supports:

• Build vs buy for an internal hook inspector. The alternative is hand-writing a Blade partial that loops FilamentView::getRenderHooks() (or equivalent) and dumps hook names into the panel. That's roughly a day of work plus ongoing upkeep. If your team wants that visibility and doesn't want to own it, buying an MIT package is the cheaper answer.
• Standardizing on render hooks as your panel-extension seam. If your roadmap says "customize Filament panels through hooks rather than forking resources," you are accepting a discovery cost: every new engineer has to learn where panels::global-search.before actually sits. A visual inspector directly reduces that cost, which makes the hooks-first architecture more defensible.
• Onboarding and support-load budgeting. A recurring support tax in Filament projects is "my widget isn't showing up." A tool that makes the hook surface visible shortens those debugging loops and lowers the number of questions routed to your one or two Filament-fluent engineers.
• Vendor/ecosystem diligence for your Filament stack. 27 stars, 0 dependents, single maintainer, no funding signal. That's fine for a dev tool and disqualifying for anything load-bearing. The decision it should drive is "is this cheap enough to adopt and easy enough to rip out?" — the answer here is yes on both counts.
• Release and environment policy. Adopting it forces an explicit decision you should be making anyway: dev-only packages are gated by APP_ENV and an authorization check, never shipped reachable in production panels. This package is a good forcing function for codifying that rule.

What it does not support — and shouldn't be sold as supporting:

• Design iteration by non-technical stakeholders. The toggle labels hooks; it does not let a designer restyle or A/B-test layouts. Screenshots and staging links do that job.
• A/B testing or runtime feature flagging. It has no programmatic control surface — no API, no per-hook enable/disable, no payload inspection. Anything that needs to be toggled by intent rather than by mouse is a flags package's job.
• Performance profiling. Hiding hook labels tells you nothing about the cost of the hooks themselves.
• A production admin-panel feature. Do not put this in front of customers or untrusted admin users; it exposes internal component structure.

When to Consider This Package

Adopt when all of the following hold:

• You run Filament 3.x or newer (the changelog tracks v4 and v5 support) and your project already uses or intends to use render hooks as the customization mechanism.
• The work is development and staging only — you can place it behind require-dev, a local APP_ENV check, and a canView gate on the plugin.
• You have more than one engineer touching the panel, or you're onboarding someone to Filament, and the "where does this hook render" loop is a recurring cost.
• You want zero build effort: a five-minute install with config-only customization (render_hook, icon, tiny_toggle) is worth more to you than a bespoke inspector you'd have to maintain.
• You're comfortable with single-maintainer risk on a dev-only dependency — acceptable precisely because the blast radius is your local environment and the code is small enough to fork or replace.

Look elsewhere — or skip entirely — when:

• You're not on Filament. The package is meaningless outside a Filament panel; it presumes the hook system exists.
• You need to do something with hooks, not see them. Programmatic toggling, per-hook enable/disable, logging, analytics, or payload inspection all require custom code. Budget a small internal partial instead; you'll get more control for comparable effort.
• You already have adequate visibility. Filament's own debugging output, Laravel Debugbar/Telescope, or browser devtools may already answer your questions. Don't add a dependency to solve a problem you've solved.
• You're on Filament 2.x or a forked/patched panel. Version-lock risk is real and the payoff is small.
• Your panels are exposed to untrusted or customer-facing admin users. A button that reveals internal hook structure is an information-disclosure surface, however minor.
• You need vendor assurance — an SLA, a security response commitment, or a roadmap you can influence. There are no dependents and no organizational backing here.
• You're optimizing for dependency minimalism. This is convenience, not capability; declining it costs you a day of engineering at most.

How to Pitch It (Stakeholders)

For executives — one paragraph, no inflated numbers. "This is a small, free, MIT-licensed developer tool for our admin panel. It adds a toggle that shows our engineers exactly where the panel's customizable slots are on any given screen, which shortens the 'why isn't this widget showing up' loop during development. It installs in an afternoon, runs only on developers' machines, and never touches production. The cost is effectively zero and the downside is contained; the upside is a few hours a month of engineering time and a faster ramp for anyone new to the framework. I'm approving it as internal tooling — not as a product feature — and I'm not attaching a productivity percentage to it, because we don't have the data to support one."

Frame the ask as: a reversible, dev-only tooling decision, not an architecture commitment. Keep it out of any customer-facing narrative.

For engineering leaders — the substance. "agencetwogether/hookshelper is a Filament panel plugin that surfaces the render hooks available on the current page behind a toggle button. It's a developer-experience tool, not a runtime dependency.

• Install as require-dev, gate it behind a non-production environment check and a canView policy, and version-pin it.
• It is config-only — hook placement, icon, and a compact toggle mode — so there's nothing to maintain beyond the composer lockfile.
• The honest risk is stewardship: one maintainer, 27 stars, zero dependents, no funding signal, releases driven by Filament version bumps. That's acceptable for a dev tool and unacceptable for anything else. Mitigation is trivial: the surface area is small and MIT-licensed, so if it stalls we fork it or replace it with an internal Blade partial in about a day.
• It is not a feature-flag system and not a performance tool. If a team asks it to do either, it's the wrong tool and I'd rather we build the twenty-line inspector ourselves than stretch this one."

For developers — how to actually use it, with the limits stated up front. "Adds a button next to the global search that labels every render hook on the current page. Click it to see the hook names in place; click again to hide them. Use it when a custom component isn't appearing, when you're placing a widget and don't know whether it belongs before or after a given hook, or when you're learning Filament's hook map for the first time.

Setup: composer require --dev agencetwogether/hookshelper, publish the config, add HooksHelperPlugin::make() to your panel's plugin array in a non-production service provider, and optionally narrow it to super-admins via canView. Publish the views if you need to restyle the toggle.

Two things it is not: it does not disable hooks — it only reveals where they are — and it does not inspect hook payloads or ordering guarantees. If you need that, write the partial yourself. Don't turn it on in a shared staging environment that's visible outside the team."