Laravel Utilities Laravel Package

Getting Started

Treat this as a grab-bag utility package, not a framework extension. Before you write a line of code, spend ten minutes confirming what is actually in it — the name promises nothing specific, and with 0 stars and 0 dependents there is no community documentation trail to lean on.

Install and pin.

composer require ollico/laravel-utilities --prefer-dist

Pin it. In composer.json prefer an explicit constraint ("ollico/laravel-utilities": "^1.0" at minimum, exact version if you can) rather than letting a floating constraint resolve on deploy. With no downstream users, minor-version churn is unvalidated by anyone but the author.

Where to look first, in this order:

1. composer.json → extra.laravel.providers and extra.laravel.aliases. This tells you whether the package auto-discovers a service provider or whether you must add it to config/app.php manually (Laravel 11+ → bootstrap/providers.php).
2. src/ directory listing. A utilities package is usually one of: a helpers.php of global functions, a set of Support/* classes, Traits/, Macros/, Rules/ (custom validators), or Facades/. The folder names tell you the intended usage pattern faster than the README will.
3. The service provider's register() and boot() methods. This is where macros, config merging, and singleton bindings live — it is the real API surface.
4. README.md last. Assume it is thin.

Enumerate what you actually got. Rather than guessing at helper names, introspect:

php artisan about          # confirms the provider booted
php artisan tinker
>>> get_declared_classes() filtered by 'Ollico'
>>> (new ReflectionClass(\Ollico\Utilities\...::class))->getMethods();

For global functions, grep the source: grep -rn "^function " vendor/ollico/laravel-utilities/src/.

First use case. Don't refactor existing code to adopt it. Pick the single helper that saves you the most typing in a new file — typically string/array formatting or a response helper — use it there, and see whether the ergonomics beat Str::, Arr::, and Number::. Utilities packages live or die on whether they beat the framework natives; test that on one real task before standardising.

Implementation Patterns

Wrap it in an application-level seam. This is the single most important pattern for a low-adoption dependency. Create App\Support\Utilities (or a small set of domain-specific classes) that delegate to the package, and call your wrapper from application code.

namespace App\Support;

class Text
{
    public static function slugify(string $value): string
    {
        return \Ollico\Utilities\...::slug($value); // package call lives here, once
    }
}

If the package is abandoned, changes behaviour, or loses a method, you patch one file instead of grepping the codebase. It also makes the helpers mockable in tests, which static helper functions otherwise are not.

Traits go on the class that owns the data. If the package ships model or request traits, apply them narrowly. A HasUtilities-style trait dumped on every model will create method-name collisions with your own scopes and accessors, and collisions surface as confusing "cannot redeclare" or silently shadowed methods. Apply per-model, and check the trait for conflicting method names first (grep -n "function " vendor/ollico/laravel-utilities/src/Traits/).

Macros: register once, in one place. If the package registers Collection/Str/Builder macros in boot(), do not also register them in your AppServiceProvider — you'll get duplicate-registration warnings or last-wins surprises. Conversely, if you want to override a macro, do it in a provider that boots after the package's (order in bootstrap/providers.php), and comment why.

Contract-test the helpers you depend on. With zero dependents there is no signal that the author's test suite covers your use case. Write a handful of cheap assertions that lock in the behaviour you rely on:

it('formats currency the way our invoices expect', function () {
    expect(\Ollico\Utilities\...::money(1234.5))->toBe('1,234.50');
});

When you bump the package, these fail loudly instead of corrupting invoices silently.

Keep it out of the domain layer. Use it at the edges — controllers, form requests, Blade, console commands, seeders. Do not call it from app/Domain or app/Models business logic, and never from a package you publish. Coupling your core to a 0-star dependency is the failure mode to design against.

Dependency hygiene. Commit composer.lock. Add the package to your Renovate/Dependabot watch list but review its diffs manually — no upstream users means no upstream bug reports. In CI, run composer validate --strict and composer audit.

Gotchas and Tips

Global helper functions are a collision hazard. If the package defines namespaced-free functions, check for function_exists() guards. If it doesn't guard, any future Laravel release that adds a same-named helper — or any other package you install — becomes a fatal error. Mitigation: audit the function list at install time, and note it in your upgrade checklist.

Double-check the release metadata. The listed last-release date (2026-10-22) is in the future relative to normal package ages and suggests a mis-parsed or force-pushed tag. Verify with composer show ollico/laravel-utilities and git ls-remote --tags before you trust the version history. A chaotic tag history is a maintenance-risk signal.

Prefer framework natives first. Laravel has absorbed most of what utilities packages used to provide: Str::of(), Arr::, Number::currency()/format()/spell(), once(), sleep(), defer(). Every helper you adopt from this package is one you must un-adopt later. Justify each one.

Auto-discovery surprises. If the provider is discovered and someone previously added it to config/app.php, you get double registration. Symptom: macros registered twice, or "already bound" exceptions. Confirm with php artisan about and check both locations.

Publishing config/assets. If there's a config file, publish it explicitly and commit the result — do not rely on mergeConfigFrom defaults, which shift between versions:

php artisan vendor:publish --provider="Ollico\Utilities\UtilitiesServiceProvider" --tag=config

Debugging missing helpers. In order: composer dump-autoload (helpers files load via files autoload, which needs a dump after install), then verify the provider boots, then check the class namespace actually matches the directory (a common flaw in small packages — PSR-4 case mismatches work on macOS and break on Linux CI). If it works locally but not in CI, it's almost always PSR-4 casing or a missing files autoload entry.

Static analysis friction. Small packages often lack docblocks, so PHPStan/Larastan will report mixed all over the calls. Rather than lowering your baseline, write a tiny stub:

// phpstan/stubs/laravel-utilities.stub
namespace Ollico\Utilities;
class ... { public static function money(float $v, string $c = 'USD'): string {} }

Extension points are likely thin. Utilities packages rarely ship interfaces. If you need to swap behaviour, you'll be extending concrete classes or decorating — feasible but brittle. The wrapper pattern above is the real extension point; lean on it.

Fork strategy for critical use. MIT license means you can fork freely (retain the copyright notice). If a helper becomes load-bearing, either vendor a trimmed copy into app/Support with attribution, or use a Composer VCS repository pointing at your fork. Given zero dependents, assume you are the only person who will ever file an issue — and that the issue may go unanswered. Plan for the package to be frozen, and make sure nothing critical breaks when it is.