Laravel Helpers Laravel Package

Getting Started

maize-tech/laravel-helpers is a grab-bag package: a service provider, a publishable config file, and a set of traits/helper functions you use inside your own classes rather than a package you interact with as a façade. Day-to-day value comes from pulling small behaviours (cache handling, array/string/config utilities, model conveniences) out of your app code.

1. composer require maize-tech/laravel-helpers
2. Laravel auto-discovers Maize\Helpers\HelperServiceProvider. Publish the config if you need to tweak defaults: php artisan vendor:publish --tag=helpers-config
3. Read config/helpers.php (or the config/ folder in the vendor tree) before the README — the package is config-driven, and the config keys tell you which behaviours are opt-in vs. always on.
4. First use case: open vendor/maize-tech/laravel-helpers/src/Traits and pick one trait, e.g. apply a caching trait to a single Eloquent model or a service class, and add it to one model only. Verify with php artisan tinker that the behaviour is what you expect before rolling it out.

As of 4.4.0 the platform floor is PHP 8.2 (8.1 support dropped) and the package supports Laravel 13. If you're on PHP 8.1 you cannot take this release — stay on 4.3.1.

Implementation Patterns

Trait-per-concern on models and services. The package's idioms are traits, so the natural workflow is: identify one behaviour you'd otherwise copy-paste (cache invalidation, attribute casting helpers, config resolution), add the trait to the narrowest class that needs it, and keep it off base classes. Because these are traits, they compose — but they also can't be swapped out later without touching every consumer, so resist putting them on a shared BaseModel.

Wrap helpers behind your own facade or helper file. Rather than calling package functions directly from controllers/Blade, alias them once (e.g. in app/Support/helpers.php or a small App\Support\Helpers facade). This gives you a single seam for testing and insulates you from package API churn — important for a package whose release notes are otherwise mostly dependency bumps.

Config-driven enablement. Publish the config into config/helpers.php and commit it. Treat the package's defaults as part of your app's contract: any behaviour you rely on should be pinned explicitly in your published config so a minor release changing a default doesn't silently alter behaviour in an unrelated PR.

Testing pattern. Use RefreshDatabase as usual; if a trait touches caching, add Cache::flush() (or use the array cache driver) in setUp and assert the outcome (query count, cache key presence) rather than the trait internals. Feature-test the consumer, not the trait.

Upgrade workflow for this release specifically. Bump require to ^4.4 only after composer why-not php 8.1-style checks confirm every environment (CI matrix, Docker images, deploy targets) is on 8.2+. Then run composer update maize-tech/laravel-helpers --with-dependencies and diff vendor/maize-tech/laravel-helpers/src between 4.3.1 and 4.4.0 — the changelog lists no code changes beyond support-matrix work, so the diff should be small; if it isn't, that's your signal to read more carefully.

Integrating with CI. Update the PHP version matrix (8.2, 8.3, 8.4) and add a Laravel 13 job only when the rest of your dependency graph supports it — this package being Laravel 13-ready doesn't mean your other packages are. Consider a composer update --prefer-lowest --prefer-stable job to catch constraint mistakes.

Gotchas and Tips

• The 4.4.0 changelog is ~all Dependabot. Six of the seven PRs touch dependabot/fetch-metadata (a GitHub Actions workflow dependency) and do not affect runtime code at all. The only substantive item is Add Laravel 13 support, drop PHP 8.1. Practical consequence: if you're on PHP 8.2+ this is a cheap, low-risk upgrade; if you're on 8.1 it's a hard block.
• Dropping PHP 8.1 is a breaking change in practice, not in semver. It shipped in a minor bump. Nothing in your code breaks, but your deploy/composer resolution does. Use composer.json's config.platform.php if you need to keep resolving locally on an older PHP than production.
• composer why-not is the fastest debug tool. When the update won't resolve, composer why-not maize-tech/laravel-helpers 4.4.0 tells you immediately whether it's your PHP constraint or a transitive package pinning an old Laravel.
• Traits collide silently. If two traits (yours + the package's) define the same method, PHP fatals at class-load time but only for classes actually using both — so a route or job that's rarely executed can be the first to blow up. Grep your trait method names before adding a new one; use insteadof in the use block if a genuine conflict exists.
• Config cache hides config edits. After changing config/helpers.php, run php artisan config:clear (or optimize:clear). A stale bootstrap/cache/config.php is the #1 "the package isn't respecting my config" cause.
• Auto-discovery can be disabled. If your app lists providers explicitly in bootstrap/providers.php (Laravel 11+ style) or has dont-discover in composer.json, the provider won't load and every trait helper will fail with "undefined method". Check php artisan about to confirm the provider is registered.
• Extension point: the package is intentionally thin — the intended customisation is to publish the config and to subclass/compose the traits in your own classes rather than to patch vendor code. If you find yourself wanting a hook, wrap the trait in a local trait that calls parent-style helpers and add your logic there.
• Pin the version in composer.json to ^4.4 and commit composer.lock. Given the package's release cadence is dominated by automated dependency PRs, an unpinned range gives you very little upside and occasional surprise support-matrix changes.