Helpers Laravel Package

Getting Started

archtechx/helpers is a small utility package that ships a set of global PHP helper functions (string/array/URL-style shorthands) for Laravel apps. It has no service provider to register, no config file to publish, and no facade — the functions are loaded via Composer's autoload.files, so composer require is effectively the whole install.

Requirements as of v0.3.4: Laravel 13 is now supported alongside the previously supported versions. If you are on Laravel 13, you must be on >= 0.3.4; earlier 0.3.x releases will not resolve against laravel/framework: ^13.0.

composer require archtechx/helpers:^0.3.4
composer dump-autoload   # functions are in autoload.files; don't skip this

Where to look first

1. vendor/archtechx/helpers/composer.json — confirms the autoload.files entry and the illuminate/support constraint (the fastest way to see whether your framework version is actually allowed).
2. vendor/archtechx/helpers/src/ — the function files themselves. Read these before using anything; each function is a handful of lines and you want to know exactly how it handles null, empty strings, and multibyte input.
3. The README function table — the canonical list of what exists. Do this before you write your own helper; there is a decent chance it is already there.

First use case: find one hand-rolled string/array manipulation in a Blade partial or a controller — the kind of three-line substr/explode dance you have copy-pasted twice — replace it with the package helper, delete the local copy, and confirm the rendered output is byte-identical. That is the cheapest possible smoke test that autoloading works and that the function's edge-case semantics match your assumptions.

Implementation Patterns

Call them directly where they read well. The whole value proposition is terseness in Blade and in short controller/accessor methods, where a fluent Str:: chain would be noise. Global functions are available in every context — HTTP, queue workers, Artisan commands, tests — because they are loaded by Composer, not by the framework.

Wrap them at the boundary if the app is large. Prefer a thin app-owned class (App\Support\Text::between(...)) that delegates to the package. Two benefits: a single grep target for every usage, and a one-file swap if you drop the package or it goes unmaintained. It also makes the call mockable in tests, which the raw global function is not.

Keep the constraint tight and explicit. Use "archtechx/helpers": "^0.3.4" rather than "*" or a floating dev-main. For 0.x packages, ^0.3.4 resolves to >=0.3.4 <0.4.0, which is the correct blast radius — see the semver note below.

Laravel 13 upgrades. Treat the package as one line item in a dependency audit rather than the driver of it:

composer why-not laravel/framework '^13.0'   # see every blocker at once
composer update archtechx/helpers --with-dependencies
php artisan test

Add Laravel 13 to your CI matrix only after the constraint bump lands, and bump all Laravel-version-sensitive packages in the same PR — a half-upgraded lockfile is where these upgrades usually go wrong.

Do not depend on it from a package you publish. Pulling in a library whose entire contribution is global functions leaks those names into every consumer's application namespace. In application code it is fine; in distributable code, inline the two lines instead.

Gotchas and Tips

• Function redeclaration is a fatal error, not a warning. If your app, a legacy app/helpers.php, or another package defines a function with the same name, you get Cannot redeclare function and every process dies — including artisan. grep -r "function your_candidate_name" app/ before you install, and again before you upgrade.
• 0.x semver means breaking changes land in 0.4.0. ^0.3.4 protects you; ^0.3 with a lockfile you never refresh does not. Review the changelog on every minor, not just every patch.
• No lazy loading. autoload.files are required on every single request and every queue worker boot. The cost is negligible for a package this size, but it also means a syntax error or a name collision in that file takes down the entire application rather than one code path — there is no scope to isolate it.
• Static analysis will not see the functions. PHPStan/Larastan and most IDE indexers do not pick up vendor global functions automatically. Add scanFiles (PHPStan) or a generated stub so you keep Call to undefined function out of CI.
• Octane and FPM need a restart after upgrading. Composer's file autoload is resolved once per worker. If a function appears "missing" after composer update, run php artisan optimize:clear and restart the workers before you start debugging the package.
• Overriding is technically possible and practically fragile. If the functions are guarded by function_exists, you can shadow one by defining your own first — but the ordering of autoload.files across packages is a Composer implementation detail, not a contract. Use the wrapper-class pattern instead.
• There is no config and no extension point. The package is a flat set of functions with a single maintainer; the realistic "extension point" is an upstream PR (the v0.3.4 change itself was a one-line constraint bump in PR #6). Plan accordingly — pin the version, keep the wrapper, and don't build architecture that assumes this package will grow.