wearedevtical/laravel-helpers
A practical collection of Laravel helpers from wearedevtical that simplifies everyday development tasks, reduces boilerplate, and provides reusable utilities for cleaner, more maintainable PHP applications. Easy to install and integrate into new or existing Laravel projects.
Architecture fit
devtical/laravel-helpers sits in the "global function autoloading" niche: a HelperManager that discovers and requires plain PHP helper files at boot, paired with artisan tooling (helper:list, make:helper, and now helper:validate / helper:reload). This is an optional convenience layer, not a load-bearing architectural component. It does not touch the request lifecycle, persistence, auth, or queue semantics. For a TPM, the correct framing is low blast-radius, high developer ergonomics — the package is easy to add and easy to remove, which keeps architectural commitment near zero. The v3.0.0 move to spatie/laravel-package-tools is a good signal: it standardises config publishing and service-provider wiring onto the de facto Laravel ecosystem convention, which reduces bespoke maintenance surface and makes the package's behaviour predictable to any Laravel developer on the team.
Integration feasibility
Feasible for any application already on PHP 8.3+. The release is a focused major, not a rewrite: no changes to the helper-loading contract are disclosed beyond added tracking and two config flags (log_errors, strict). The publish tag rename (helpers-config) is a one-line change in deployment scripts and runbooks. The new spatie/laravel-package-tools dependency is ubiquitous in the Laravel ecosystem and unlikely to create conflict, but it does enter the dependency graph and therefore the supply-chain and version-constraint review. The genuinely valuable additions from an integration standpoint are helper:validate (syntax checking plus duplicate-function detection — duplicate function declarations across helper files are the classic fatal-error failure mode of this pattern) and helper:list --json, which turns an interactive command into something a pipeline can assert on.
Technical risk Overall: low, with three concrete blockers to check before adoption.
strict and log_errors. The notes introduce these flags without stating their default values or runtime semantics. If strict defaults to on and converts a previously silent failed load into an exception, an upgrade could turn a degraded-but-serving app into a boot failure. This must be read from the config stub before any rollout — it is the single highest-value unknown in this release.Call to undefined function — a runtime, not boot, failure. Logging makes this diagnosable; it does not make it safe.Secondary risk: make:helper stub changes (declare(strict_types=1)) will produce files stylistically inconsistent with existing helper files until the team regenerates or back-fills, creating minor review friction.
Key questions
strict and log_errors, and does strict change boot-time behaviour on a failed load?helper:list --json output schema stable enough to assert on in CI, or explicitly documented as unstable?helper:validate duplicate-detection catch cross-file redeclarations at CI time, i.e. can it fully replace manual review of helper additions?Stack fit
Good fit for a Laravel monolith or a small number of Laravel services that share a convention of global helper functions. Poor fit for teams already standardised on class-based utilities, Str/Arr/Collection macros, or namespaced helpers — in those codebases the package adds a parallel mechanism with no owner. Confirm which camp the codebase is in before scoping any work.
Migration path
devtical/laravel-helpers to ^2.1 in composer.json today if not already constrained; v2.1.0 remains the safe target until step 2 clears.^3.0.php artisan vendor:publish --tag=helpers-config. Update every reference to the old tag in deploy scripts, Dockerfiles, bootstrap scripts, and onboarding docs — this is the most likely place for a silent regression, because a stale tag fails quietly rather than loudly.strict and log_errors, then set them explicitly rather than inheriting defaults.helper:list before and after on a representative environment; confirm identical function inventory and no failed entries.Compatibility
The spatie/laravel-package-tools addition should be checked against the app's existing Spatie packages for constraint overlap. Verify the Laravel version support matrix stated by v3.0.0 against the app's framework version — the notes do not state it, which is itself a question to close.
Sequencing
Trunk-first, one service at a time: upgrade a non-production or lowest-traffic service, run the before/after helper:list diff, hold for one release cycle, then propagate. helper:reload is development-only and should not be relied on in staging or production runbooks. Add helper:validate to CI before the version bump lands broadly — it costs nothing on v2 and pays off immediately by catching duplicate declarations regardless of package version.
Maintenance
Positive trajectory: PHPStan level 5 and Pint in CI signals a maintainer investing in static analysis and style consistency, which correlates with fewer surprise regressions. The spatie/laravel-package-tools migration moves boilerplate out of the package and onto a maintained upstream. Counterweight: this is a small, likely single-maintainer package in a convenience niche. Treat it as a replaceable dependency — the removal cost is low (delete helper files, inline the functions), which is the right hedge and should be stated in the ADR.
Support
Support burden is low and mostly self-inflicted: a failing helper file is a developer-authored defect, not a package defect. helper:validate shifts detection left into CI, which should measurably reduce "works locally, fatal in prod" incidents. log_errors gives on-call a paper trail where previously a partial load may have been invisible until a function call failed.
Scaling
Scales trivially — helpers are loaded once at boot, no per-request cost. The scaling concern is organisational, not technical: unbounded helper accumulation creates a global namespace with duplicate-name collisions and no clear ownership. helper:list with function count and --json output is the right lever here — use it as a periodic inventory report to flag growth and unreferenced helpers.
Failure modes
strict escalates it to boot time, which is arguably preferable.helper:validate in CI if wired up.Ramp-up
Near-zero for any Laravel developer: the artisan commands are self-documenting and the mental model ("PHP files in a folder, autoloaded") is immediately graspable. Budget roughly half a day per service for the upgrade itself and the config-tag sweep, plus a short ADR recording the PHP floor decision, the explicit strict/log_errors settings, and the CI gate on helper:validate. The main onboarding risk is cultural rather than technical: without a stated policy on when to add a global helper versus a class, the helper directory becomes an unowned dumping ground.
How can I help you explore Laravel packages today?