Laravel Dynamic Helpers Laravel Package

Product Decisions This Supports

• Build vs. buy for helper scaffolding. The package is essentially a convention plus a generator (php artisan make:helper) and a resolver. A PM can use it to answer "do we spend sprint time building our own app/Helpers convention, or adopt a 200-line MIT package?" Default answer: adopt only if the convention matches how the team already writes utility code; otherwise the build cost is a day, not a sprint.
• Developer-experience roadmap bets. It directly targets onboarding velocity and code organization friction — "where do utility functions live?" and "how do I call them?" If DX/onboarding is a stated quarterly objective, this is a cheap line item to test.
• Standardization of an existing mess. Most Laravel codebases have a helpers.php full of global functions, a few app/Support classes, and inconsistent naming. This package formalizes that into classes under app/Helpers with one naming rule (nested path → flattened camelCase). That is a code-hygiene decision, not a capability decision.
• Feature scope call: three access patterns. v2.0.0 offers global functions (moneyHelper()), static calls (MoneyHelper::format(100)), and proxy (helpers()->moneyHelper()). A PM should decide one as the house style and explicitly discourage the others — offering three paths to the same object is a convention-consistency risk, not a feature. The static-call path in particular makes helpers trivially mockable-in-name-only and encourages service-locator-flavored code.
• Not a decision it supports: it does not unlock new product capability. Nothing here ships a customer-facing feature. Treat it strictly as an internal tooling line item and size the decision accordingly.

When to Consider This Package

Adopt (pilot-only) when all of the following hold:

• You are on Laravel 11+ / PHP 8.1+ (v1.3.0 dropped Laravel 10; there is no supported path for older apps).
• You already have, or are actively consolidating, a sprawl of helper functions and want an enforced convention with scaffolding.
• The team is willing to pin a version, review the source (~small), and fork if abandoned. With 1 GitHub star, 0 dependents, and a single maintainer, this is a "vendor it, don't depend on it" dependency.
• The usage is confined to non-critical paths — formatting, permissions checks, API wrappers — not money movement, auth decisions, or anything on a compliance boundary.

Look elsewhere when any of the following apply:

• eval() at boot time is disqualifying. v2.0.0 creates real global functions via eval() during service-provider boot and writes _ide_helper.php / .phpstorm.meta.php to disk on every boot cycle, plus auto-appends to .gitignore. That is a security-review and CI-artifact question in most enterprises. If your org has a static-analysis gate, an eval ban, or read-only production filesystems, stop here.
• You need maturity signals. 1 star, 0 dependents, one maintainer, and a v1→v2 major that removed a shipped Artisan command (helpers:ide) and changed boot behavior. Bus factor is 1 and the API has already broken once.
• You want IDE autocomplete without boot-time side effects. barryvdh/laravel-ide-helper is the established, widely-adopted answer to the autocomplete half of this problem.
• You want real dependency injection. Helpers resolved as singletons and reached through global functions are the opposite of DI. If the codebase is moving toward constructor-injected services, this package points the architecture backwards.
• You are a small team that can just write app/Support/Money.php and app(SomeHelper::class). The package's value over that is the generator command and the global-function ergonomics — real, but modest.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed developer-convenience package for our Laravel apps. It standardizes where utility code lives and adds an artisan make:helper command so engineers stop hand-rolling and copy-pasting helper functions. Expected benefit is modest but real: faster onboarding, less bikeshedding over file placement, cleaner code review. It adds no customer-facing capability, carries no license cost, and is trivially removable. Risk is maintainer abandonment — the project has one author and effectively no community — so the recommendation is a time-boxed pilot on one internal, non-critical service, pinned to a specific version, with the source vendored/forks under our control.

To engineering: The value is the convention and the generator, not the resolution machinery. Two things need explicit sign-off before we merge it: (1) v2.0.0 creates real global functions via eval() at service-provider boot and regenerates IDE stub files on disk every boot — confirm that passes our security/static-analysis posture and that production filesystems are writable or the writes are guarded; (2) we must pick one of the three access patterns as house style — global functions plus make:helper is the ergonomic win, static calls via __callStatic are the one I'd ban, because it invites service-locator patterns we're trying to move away from. If either check fails, the fallback is barryvdh/laravel-ide-helper for autocomplete plus a plain app/Support namespace, which gets us ~80% of the benefit with zero new dependencies.

Decision requested: approve a one-service pilot; success looks like helpers created via the command and consistently consumed by one access pattern within a sprint, with no eval or filesystem complaints from the security review. Exit criteria: if either the eval/file-write check or the convention-adherence check fails, we drop the package and standardize on app/Support classes.