Helpers Laravel Package

Getting Started

• Install with composer require berlioz/helpers. There is no service provider, no facade, no config file, no publish step — it's a grab-bag of namespaced PHP functions loaded via Composer's autoload.files, so they exist on every request immediately after composer require.
• Read composer.json first, then the src/*.php files grouped by domain (string.php, array.php, path.php, url.php, file.php, class.php, date.php, misc.php). That tree is the only real documentation — there is no Laravel-facing guide.
• Because the functions are namespaced, bring them in per file: use function Berlioz\Helpers\strContains; (or call fully qualified \Berlioz\Helpers\strContains()).
• First realistic use case: a quick plain-function string check or path normalization without pulling in Illuminate\Support\Str. Drop it into a small utility class or trait so you're not scattering namespaced imports across controllers.

Implementation Patterns

• Import individually, alias on collision. use function Berlioz\Helpers\strContains as berliozStrContains; keeps intent obvious and avoids surprises if two packages define similar names.
• Wrap what you depend on. Put the handful of functions you actually use behind one app-level class (e.g. app/Support/Text.php). You get grep-ability, a single swap point, and testability if you ever want to mock or replace them.
• Path helpers are the strongest candidate for real use — pathNormalize / pathConcat-style utilities fill a gap when you're handling Windows-vs-*nix strings outside Storage::path() or before a realpath() call.
• Typed array getters (getString, getInt, getBool, getArray-style helpers) are convenient when consuming mixed-shape config arrays from a package or a third-party payload — arguably cleaner than Arr::get() plus a manual cast, provided you verify the exact fallback semantics.
• URL string helpers (getUrlPath, getUrlQueryParams, getUrlFragment) are useful in queued jobs and CLI contexts where request() isn't meaningful and you just have a raw URL string.
• File introspection helpers (fileSize*, MIME checks) are fine for read-only usage where you don't want Flysystem in the dependency graph.
• These are pure functions with no container dependency — treat them as unit-testable in isolation.

Gotchas and Tips

• Heavy overlap with Laravel. Str::contains, Str::startsWith, Arr::get, and helpers.php already cover most of the package. Prefer Laravel's versions for anything you'll assert against Laravel behavior, and reserve the package for genuine gaps (path normalization, URL string parsing, some typed getters). Divergent edge-case behavior between two contains() implementations is a classic source of confusing test failures.
• Global autoloading is unconditional. Since it's autoload.files, the functions always load — no lazy loading, no way to opt out per request. Minor, but real.
• Namespaced imports are mandatory. Forgetting use function silently gives you a "call to undefined function" error rather than a class-not-found, which is easy to misread as an autoloader problem.
• Don't assume Laravel semantics. The typed getters may coerce/null-fill differently from Arr::get() (e.g. returning '' vs null for a missing key). Read the source of the specific function before relying on defaults.
• Filesystem edge cases. Some helpers may not honor open_basedir or resolve symlinks the same way Laravel's Storage/Filesystem does — test in your target environment before putting them on a critical path.
• No IDE stubs or type hints worth trusting. Rely on PHPStan/Psalm with generous use function imports, or expose signatures through your own wrapper class.
• Debugging: composer show berlioz/helpers, then grep vendor/berlioz/helpers/src. get_defined_functions()['user'] filtered by the Berlioz\Helpers\ namespace will show you exactly what's loaded. There's no config to debug — a failing call is almost always an import or autoload issue.
• Extension model: there isn't one. If you need a behavior it lacks, write your own namespaced function and use function it the same way. That's the entire "framework" here — small, stateless, and best treated as a personal utility belt, not a dependency you build architecture on.