Laravel App Helpers Laravel Package

Getting Started

mPhpMaster/laravel-app-helpers is a grab-bag of global helper functions for Laravel apps (app/model/class-name introspection, locale and RTL helpers, formatting utilities). It ships no service provider surface you must wire up manually in most setups.

1. Install and pin deliberately, since 2.0.0 is a major bump with no changelog detail:

   composer require mphpmaster/laravel-app-helpers:^2.0
   

2. Confirm the helpers file is actually autoloaded — the package (like most helper packages) registers a files entry in its composer.json. Check with:

   composer dump-autoload -o
   php -r "require 'vendor/autoload.php'; var_dump(function_exists('current_lang'));"
   

3. Look first at vendor/mphpmaster/laravel-app-helpers/src/ and any helpers.php / *Helpers.php file there. That file is the real API — helper packages rarely document every function, and the source with its if (! function_exists(...)) guards is the authoritative list for your version.
4. Publish config only if the release ships one:

   php artisan vendor:publish --provider="mPhpMaster\LaravelAppHelpers\LaravelAppHelpersServiceProvider"
   

5. First use case: call a helper directly from a controller or Blade view to resolve the current locale or the calling model's short name, e.g. current_lang() or getModelName($model), instead of hardcoding app()->getLocale() or class_basename() everywhere.

Because the 2.0.0 notes contain only a PR link, treat the upgrade as unknown-risk: run git diff 1.0.3 2.0.0 -- src/ against the tag before adopting, or install 1.0.3 first and diff behaviour against a scratch branch.

Implementation Patterns

Call helpers at the edges, not in domain code. These are global functions, so they are convenient in controllers, Blade, form requests, and Artisan commands, but they make your domain layer untestable in isolation. Wrap them:

final class Locale
{
    public static function current(): string
    {
        return current_lang() ?? app()->getLocale();
    }
}

Then a future 3.0.0 rename only touches one file.

Feature-detect rather than assume. Helper packages accumulate and drop functions across majors. If you depend on a subset, assert it at boot (or in a Pest/PHPUnit smoke test) so a composer update fails loudly:

it('provides required app helpers', function () {
    foreach (['current_lang', 'getModelName', 'isRtl'] as $fn) {
        expect(function_exists($fn))->toBeTrue();
    }
});

Use them for Blade presentation only. Locale direction, number/date formatting, and class-name derivation are presentation concerns. Anything that mutates data or touches persistence should stay in your own services.

Compose with Laravel's own APIs. Most helpers duplicate a facade call with sugar. Prefer the helper only where it saves real boilerplate (e.g. getModelName() over Str::of(class_basename($model))->snake()), and use app(), config(), Lang:: directly otherwise — fewer moving parts during a major upgrade.

Package-scope config overrides. If a config file is published, keep any overrides in config/laravel-app-helpers.php and commit it; the helper functions frequently read config() at call time, so config caching applies.

Gotchas and Tips

• 2.0.0 has no migration notes. The release body is a single PR link. That is the single biggest risk here: a major version with an undocumented diff. Before upgrading in production, diff the tags and grep for renamed or removed function names:

  git diff 1.0.3 2.0.0 -- src/
  

  Then search your codebase for every helper you call and confirm it survives.
• Global namespace pollution. Helpers are defined as bare functions in the root namespace and generally guarded with function_exists(). If two packages define the same name, whichever autoloads first wins silently. If a helper mysteriously returns the wrong value, check for a collision before debugging the package.
• composer dump-autoload is mandatory after upgrading. The files autoload entry is resolved at dump time; a stale vendor/composer/autoload_files.php can leave you running 1.0.3 code against a 2.0.0 lockfile.
• Config caching. If helpers read config at call time, php artisan config:cache during deploy is fine, but changing config values without re-caching will not take effect. Run php artisan optimize:clear when behaviour looks stale.
• Performance is negligible but not free. files autoload runs on every request including queue workers and Octane. After upgrading, restart Octane workers (php artisan octane:reload) — otherwise long-lived workers keep the old function definitions.
• Extension point is the function guard. You cannot subclass a helper. If you need different behaviour, define your own function or wrapper class first in your own app/helpers.php and let the function_exists() guard in this package skip its version — but only do that deliberately and document it, because it silently masks package upgrades.
• Debugging: function_exists($fn) to confirm presence, (new ReflectionFunction($fn))->getFileName() to confirm which file defined it, and composer show mphpmaster/laravel-app-helpers to confirm the installed version. That trio resolves most "helper not found / wrong helper" reports in one pass.