Weave Code
Laravel Namespaced Helpers Laravel Package
revolution/laravel-namespaced-helpers
Laravel Namespaced Helpers lets you organize custom helper functions into PHP namespaces instead of polluting the global scope. It offers a simple way to register and autoload namespaced helpers, helping larger Laravel apps avoid function-name collisions and keep utilities structured.
At a glance
Frequently asked questions about Laravel Namespaced Helpers
- How do I install revolution/laravel-namespaced-helpers?
- Install it with the Composer command: composer require revolution/laravel-namespaced-helpers. The function files are autoloaded by Composer, so there is nothing else to run. There is no service provider to register, no config file to publish, and no migrations or assets involved.
- Do I need a service provider or configuration file to use it?
- No. The package is documented as zero configuration and drop-in ready, which means installing it is the entire setup. Functions become available through Composer's autoloader rather than through a Laravel bootstrap step. That also means removal is just a composer remove plus reverting your imports.
- How do I call a namespaced helper — do I need use function imports?
- Yes, you import each helper explicitly with a use function statement, then call it like a normal function. Only the helpers you import are in scope, which is the whole point: nothing is silently available everywhere. The trade-off is that a bare call site such as str() can be ambiguous to a reviewer unless the import is visible in the same file, so keep imports at the top and prefer fully qualified calls in code where clarity matters most.
- What is the difference between these helpers and Laravel's built-in global helpers?
- The behaviour mirrors Laravel's helpers, but the functions live in an explicit PHP namespace instead of the global scope. That gives you traceable, IDE-friendly resolution and removes the risk of a name collision with application or third-party code. Because the functions are namespaced, static analysis tools see a concrete, resolvable signature rather than an implicitly global function.
- Which Laravel and PHP versions does the package support?
- Support is defined by the php and illuminate/support constraints in the package's composer.json, and you should read those directly rather than assume. Validate the constraint against the exact Laravel minor version you run in production, not just the major, because illuminate/support is version-locked to the framework and is the most common source of install conflicts. If the package pins an end-of-life PHP minor, treat that as a disqualifier regardless of how useful the helpers are.
- Will it conflict with laravel/helpers or my app's existing helper functions?
- No, because namespaced functions do not occupy the global function table, so they cannot collide with global helpers or your own function definitions. The realistic install risk is not a function collision but a Composer constraint conflict on illuminate/support. Check for overlap with any existing helper-shim or macro package before adding another convention to the codebase.
- Can I use it in a Composer package I publish for other Laravel apps?
- This is the strongest use case. A library that calls Laravel global helpers imposes an implicit dependency on a booted framework and on helpers existing globally, whereas namespaced imports are explicit and predictable for consumers. Keep the illuminate/support constraint wide enough for downstream apps, and avoid container-dependent helpers in library code that may run outside a booted app.
- How do container-dependent helpers such as config(), app(), and __() behave?
- Those helpers depend on a booted application and container, so outside a real Laravel bootstrap they behave exactly as their global counterparts do, which usually means failing or returning defaults. That matters if you use this package in shared modules or standalone component libraries, where only container-free helpers are safe. Verify in the source whether the package delegates to Laravel's own implementations or reimplements behaviour, since reimplementation means you inherit every future framework change.
- How do I test code that uses these namespaced helpers?
- Because the functions ship through Composer's autoloader, your normal PHPUnit suite picks them up without extra bootstrapping. Tests for container-dependent helpers still need a real application instance, so run a smoke test under the actual bootstrap rather than a bare unit test. It is also worth running your PHP-CS-Fixer native_function_invocation rule and PHPStan or Larastan baseline, because if tooling resolves the global signature instead of the namespaced one you lose the static-analysis benefit that justified the change.
- Is revolution/laravel-namespaced-helpers maintained and safe for production?
- The engineering risk is low because the package is small, patches nothing globally, and can be removed with a single composer remove plus a file revert. The real risk is provenance: it has minimal public adoption, a single maintainer, and no documented security policy, release cadence, or upgrade policy tied to Laravel majors. If you adopt it, pin the version, read the source, and be prepared to fork and own it if it stops tracking framework releases.
Weaver
How can I help you explore Laravel packages today?