Laravel Helpers Laravel Package

Getting Started

Install via Composer on PHP 8.0+ / Laravel 10.0+ (v3.x dropped support for older Laravel — see Gotchas):

composer require rmunate/laravel_helpers

Pin the major explicitly in composer.json; the maintainer recommends it in the release notes:

"rmunate/laravel_helpers": "^3.0"

First thing to read is the package documentation (https://rmunate.github.io/LaravelHelpers/), not the source — the whole point of v3 is a standard, and the docs define the helper categories and the class catalog. Skim the category list before writing anything, because half of what you're about to hand-roll probably already ships as a class (the package re-exposes Laravel's own helpers via classes like Str:: and Arr::, alongside its own categories).

Then create your first helper class. The package's contract is simple: helpers are classes with static methods, not global functions, so they're callable from any class or view without use function imports:

namespace App\Helpers;

class MoneyHelper
{
    public static function formatUsd(float $amount): string
    {
        return '$' . number_format($amount, 2);
    }
}

Call it from anywhere — controllers, jobs, Blade:

<p>{{ \App\Helpers\MoneyHelper::formatUsd($invoice->total) }}</p>

First real use case: inventory your existing app/Helpers/*.php free functions and app/Support/Utils.php grab-bag, then port them to named classes. The migration is mechanical (use function App\helpers\format_usd; → MoneyHelper::formatUsd(...)) and it's exactly the standardization the package exists to enforce.

Implementation Patterns

One class per concern. StrHelper, DateHelper, MoneyHelper, ArrayHelper. Keep methods pure (input → output, no DB, no HTTP). This is the sweet spot for the package.

Check the built-in catalog before writing. v3 centralizes Laravel's existing helpers by category and exposes the class-based ones (Str::, Arr::) through the package. Before you write MoneyHelper::toArray(), check whether a package helper already covers it — otherwise you end up maintaining a parallel, subtly different implementation.

View-layer helpers via Blade. Helpers are static and dependency-free, so direct calls keep templates readable:

@if(\App\Helpers\DateHelper::isWeekend($event->starts_at))
    <span class="badge">Weekend</span>
@endif

For repeated calls, register a Blade directive in a service provider instead of repeating the FQCN in every view.

Facade wrapper for DI-friendly code. If you want to swap helpers in tests or replace the implementation later, wrap one in a facade:

class Money extends Facade
{
    protected static function getFacadeAccessor(): string
    {
        return MoneyHelper::class;
    }
}

Now Money::formatUsd(...) flows through the container and is mockable.

Chained helper composition. Because helpers are static, one helper can call another — e.g., InvoiceHelper::summary() composing MoneyHelper + DateHelper. Keep the graph shallow; deep chains make debugging hard.

Testing pattern. Pure functions → trivial unit tests, no Laravel bootstrap, no DB:

public function test_usd_format(): void
{
    $this->assertSame('$1,234.56', MoneyHelper::formatUsd(1234.56));
}

Migration path from legacy helpers. Wrap each function in a static method with the same signature, migrate call-sites, then deprecate the free function. Do it class-by-class so you can run the old and new paths side by side during the transition.

Gotchas and Tips

• v3 is a platform break. The release notes state PHP 8.0+ and Laravel 10.0+. If you're still on Laravel 8/9, you cannot take this upgrade — stay on v2.x and pin it. Confirm in the package's composer.json require before bumping in a long-lived app.
• Pin the major. "rmunate/laravel_helpers": "^3.0" is the maintainer's own recommendation. Major-version helper packages are exactly where a silent composer update bites you.
• Upgrading from 2.x: re-read the docs, not just the diff. The v3 pitch is a reorientation of the package toward classes and centralized Laravel categories. Verify method signatures and namespace paths against the docs for each helper you use, and check for an upgrade guide — the release notes themselves do not enumerate per-helper API changes.
• Autoload your helpers directory. app/Helpers/ is not PSR-4 autoloaded by default. Add it to composer.json autoload.psr-4 ("App\\Helpers\\": "app/Helpers/") and composer dump-autoload after generating new files.
• Static = singleton by accident. Static caches, counters, or mutable arrays on a helper leak across tests and across requests under Octane. Keep helpers stateless, or reset explicitly in tearDown.
• Naming collisions with Laravel's built-ins. StrHelper, ArrHelper, NumberHelper will shadow/confuse developers who know Illuminate\Support\Str. Namespace them clearly (App\Helpers\XxxHelper) and don't redefine what the package already exposes.
• Don't use helpers for business logic. A helper calling Eloquent, sending mail, or hitting an API breaks the pattern and makes mocking painful. Move that to a service class; keep helpers pure.
• IDE autocompletion is limited. Static calls in Blade won't autocomplete without ide-helper. For DX, prefer facade imports in app code.
• Debugging resolution: a temporary dd(class_exists(MoneyHelper::class)) in AppServiceProvider::boot() tells you instantly whether the problem is autoloading/config or the package.
• Blade escape gotcha. Helpers returning HTML need {!! ... !!} — easy to break escaping when migrating from a view composer to a static helper. Be explicit in the docblock that a method returns safe HTML vs. escaped text.
• Low-traffic package. Small star count and a single maintainer; budget for reading the source when the docs are thin, and don't make it load-bearing for anything you can't replace in an afternoon.