Laravel Blade Helper Laravel Package

Product Decisions This Supports

• Optional-feature rendering in Blade views. The package's core value is answering "is this Blade directive registered?" (e.g. BladeHelper::hasDirective()) so a view can emit @vite, @livewireStyles, an analytics directive, or a first-party add-on's directive only when the provider is actually installed. This supports decisions like: ship one shared layout across product tiers instead of forking views per edition, and let add-on/module packages contribute directives without the host theme hard-coding them.
• Build vs. buy. The capability is small but fiddly (introspecting Laravel's Blade compiler and its custom-directive registry). Adopting a maintained micro-package beats owning that introspection in-house, where it silently breaks on framework internals changes.
• Packaging strategy for our own add-ons. If we publish packages whose views are consumed by applications we don't control, conditional directive checks let those views degrade gracefully rather than throwing "directive not defined" errors — a support-ticket reducer and a real DX selling point.
• Framework upgrade roadmap. v1.7.0 adds Laravel 13 support. That keeps this dependency off the critical path for a Laravel 13 upgrade; no migration work or code changes are implied for consumers.
• Test ergonomics. Compiling/inspecting a Blade fragment in isolation (rather than booting a full view) makes it cheap to assert "this block renders for tier A, not tier B" in feature tests — useful for gating logic that would otherwise be validated only by clicking through the UI.

When to Consider This Package

Adopt it when:

• You ship Blade views, layouts, or Blade-emitting packages that reference directives which may or may not exist in the host app (optional packages, white-label themes, tiered/edition builds).
• You want conditional directive output driven by what is actually registered rather than by a parallel config flag or env var that can drift out of sync with reality.
• You maintain an add-on whose views are rendered inside customer applications you don't control, and you want those views to fail soft.
• You are planning or currently executing a Laravel upgrade — v1.7.0 explicitly tracks Laravel 13.

Look elsewhere when:

• You need to define directives. Use Blade::directive() directly; this package is for discovery/registration plumbing, not directive authoring.
• You need real Blade AST/compiler manipulation, custom compilers, or component-level runtime logic. That's a compiler extension, Blade components, or view composers — not a helper facade.
• Your conditional is genuinely about configuration (feature flags, plan entitlements, env). Use @if/config; a directive-existence check is a proxy, not a substitute, for a business rule.
• You're already on a micro-dependency diet and this is load-bearing: the surface area is small enough to vendor a handful of methods and remove the supply-chain/maintenance question entirely.
• Version pinning note: the PHPUnit 12 / #[Test] migration in v1.7.0 is a dev-only change. It does not affect consumers and imposes no PHPUnit constraint on your application.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-risk utility that lets our Blade templates render optional features cleanly — showing an integration's markup only when that integration is actually present. The practical payoff is fewer broken pages and support tickets when a module isn't installed, and one shared set of templates across product tiers instead of per-tier forks. The v1.7.0 release is purely additive: Laravel 13 support, no breaking changes, no deprecations. It costs us nothing to take and it keeps our framework upgrade path clear.

For engineering (one paragraph): v1.7.0 adds Laravel 13 support and modernizes the package's own test suite (PHPUnit 12 schema, #[Test] attributes) — dev-only, no impact on our dependency graph. Upgrade is a composer update with no code changes expected; the 1.x line has been non-breaking. Use it where we currently guard optional directives with try/catch, isset checks, or duplicated layout files, and swap those for a directive-registry check. Do not use it as a feature-flag system — business gating stays in config. If we end up depending on it in more than a couple of places, revisit vendoring the ~200 lines; the maintainer bus factor, not the code, is the risk.

Decision asked of stakeholders: approve the version bump to v1.7.0 (no action required beyond routine dependency updates) and approve the pattern — directive-existence checks in shared layouts — as the standard approach for optional Blade directives in new packages.