Laravel Helpers Laravel Package

Product Decisions This Supports

• Convention decision: class-based helpers vs. global functions. The package formalizes "helpers" as classes invokable from any controller, service, or Blade view. v3.1.0 sharpens this into an explicit doctrine: helpers should be classes, and even native Laravel function-style helpers should be reached through categorized class wrappers (Str::, Arr::) where they exist. That is a codebase-wide architectural convention, not a feature toggle — worth an explicit ADR.
• Framework-version gate (new in v3.1.0). The package now declares PHP 8.0+ and Laravel 10.0+. This is a hard floor: if any part of your estate is still on Laravel 8/9, v3 is simply not an option there, and you cannot standardize the convention across the whole organization on this package today. That constrains the scope of any adoption decision to the Laravel 10+ portion of your portfolio.
• Build vs. buy. The value proposition remains: a service provider, a discovery/registration mechanism, and an invocation API — plus a documentation site and a categorization convention layered on top. A mid-level Laravel engineer can replicate the mechanics in an afternoon. Treat this as buy-with-a-fork-plan, not buy-and-depend. The new release adds documentation and convention, not defensible technology.
• Roadmap input for platform/DX work. If multiple teams are writing ad-hoc helpers.php files, this package is a cheap forcing function to consolidate them into testable, autoloadable classes. That is a small but real reduction in "where does this function live?" support load. The v3.1.0 "standardization" framing is a useful narrative for that consolidation work — you can cite the convention without necessarily adopting the dependency.
• Legacy modernization sequencing. For a Laravel 10+ app migrating toward typed services and DI, class-based helpers are a reasonable intermediate step. It is not a destination — helpers remain globally reachable and bypass constructor injection — so position it as a transitional pattern in the migration plan, not the target architecture. For Laravel 8/9 apps, the version floor removes this option entirely; plan a different interim pattern there.
• Dependency-policy decision (strengthened by this release). v3.1.0 ships as a README-style announcement with no changelog, no breaking-change disclosure, and no deprecation policy, while the docs instruct users to declare a floating "^3.0" constraint. The decision this forces is whether your team accepts minor-version drift from a single-maintainer package with no change-management artifacts. Recommended answer: no — pin exactly, regardless of what the README suggests.
• View-layer utility strategy. Calling helpers from Blade is convenient but is also the fastest route to logic-in-templates. The decision this package forces is: do we permit helper calls in views, and if so, which helpers? That belongs in your frontend/Blade guidelines.
• Explicitly not supported: any decision requiring long-term vendor confidence. The package is still a single-maintainer project with minimal downstream adoption and no evidenced support commitments. A documentation site and a 3.1.0 release do not change that risk profile — they change the onboarding cost, not the durability.

When to Consider This Package

Consider it when:

• You are a small team (or solo) on a greenfield or early-stage Laravel app, already on Laravel 10+ / PHP 8+, with no existing helper convention, and you want class-based helpers working in under an hour without designing the pattern yourself.
• Your helper surface is genuinely cross-cutting — formatting, string/number transforms, domain-agnostic calculations — used from both HTTP and view layers, and you do not want to thread dependencies through constructors.
• You value the documented convention more than the code. v3.1.0's real contribution is a written standard plus a browsable docs site. If your team needs a reference pattern to align on, this is a usable one to cite — and to reimplement if the package stalls.
• You need a fast, reversible trial: the footprint is small, an evaluation spike is a day, and backing out is a composer remove plus a mechanical refactor to plain classes.
• You accept that you are effectively the maintainer if the package goes quiet, and you are comfortable pinning an exact version.

Look elsewhere (or write it yourself) when:

• You are on Laravel 8 or 9. v3.0+ requires Laravel 10+. Do not adopt an older major just to satisfy a convention — that trades a trivial refactor for an unsupported dependency.
• You already have laravel/helpers, a house helpers.php, or a Support namespace. Introducing this adds a third convention for zero net gain.
• Your helpers need real dependencies. Once a helper requires repository or HTTP-client injection, it is a service — bind it in the container, don't make it globally reachable. The package's ergonomics actively encourage the wrong shape here.
• Supply-chain or maintenance risk is material — regulated environments, security review gates, or a codebase expected to outlive the next two years. Low stars and zero dependents mean no community pressure to fix issues or ship disclosures.
• You need guarantees: semantic versioning discipline, a changelog, a deprecation policy, a security disclosure process, an explicit Laravel-version support matrix with a lifecycle. v3.1.0's release notes provide none of these — they are marketing copy plus install instructions.
• Your team is PHPStan/Larastan at level 6+. Globally invokable helpers are difficult to trace statically and produce dynamic-call blind spots.
• Recommendation for most teams scoring this objectively: evaluate, do not adopt. The underlying problem is real; the solution is thin, easily substituted, and now carries a framework floor that will fragment adoption across a mixed-version estate. That remains a "steal the pattern, skip the dependency" situation.

If you do adopt: pin the version exactly (ignore the README's "^3.0" advice — an unreviewed minor bump from a package with no changelog is exactly the risk you're trying to bound), wrap invocations behind your own thin facade so the package is a one-file swap, and add a test that asserts each helper class is registered. Never let package helpers be called directly from more than one layer.

How to Pitch It (Stakeholders)

For executives — one line: "A small, MIT-licensed convenience library that standardizes how our Laravel app stores reusable utility code. Cheap to try, trivial to remove, not something to build a strategy on."

The business case: We scatter small reusable functions across ad-hoc files, which makes them hard to find, hard to test, and easy to duplicate. This package imposes a light, documented structure — helpers as classes, callable from anywhere — with no licensing cost and no infrastructure change. Worst case we spend two engineering days on a spike and revert.

What changed in this release (say this plainly): v3.1.0 adds a documentation site and a clearer opinion that helpers should be class-based, and it formally raises the floor to Laravel 10+ / PHP 8+. It does not add a changelog, a deprecation policy, a security process, or additional maintainers. It is a packaging and messaging release, not a maturity milestone.

The honest risk statement (say this out loud): Adoption remains low, the dependency has effectively no downstream projects, and it is maintained by a single author. Translation: if it breaks or is abandoned, we fix it ourselves. The good news is that the fix is small — the behavior is replicable in-house in roughly a day, so our exposure is capped at a refactor, not a migration. And because the package now requires Laravel 10+, this cannot become an org-wide standard anyway while parts of the estate remain on older versions.

For engineering: It solves a real ergonomics problem — helper logic becomes autoloaded, namespaced, and unit-testable instead of living in a files-autoloaded grab bag, and the new docs give us a reference convention. But it also makes every helper globally reachable, which quietly undermines dependency injection and static analysis, and the release notes recommend a floating ^3.0 constraint from a package that publishes no changelog. Proposed position: use it as a transitional convention on one Laravel 10+ service, wrapped behind our own facade, pinned to an exact version, with the expectation that we replace it with plain container-bound classes as the codebase matures.

Ask: Approve a two-day spike and a written ADR covering the helper convention and the pinning policy. Success criteria — helper duplication drops on the pilot service, no new helpers are added that require injected dependencies, and no production service resolves a floating constraint to this package. If any criterion fails, we keep the class-based pattern, write it down ourselves, and drop the dependency.