Support Laravel Package

Getting Started

This is a small, MIT-licensed utility package from the LaravelHA ecosystem — helpers, a base service provider, and shared traits — not a feature package. Treat it as source code you are evaluating to read, not infrastructure you are adopting.

Install into a scratch branch:

composer require laravelha/support
composer show laravelha/support   # read the illuminate/* constraints before anything else

The last release was 2020-10-07, which puts it in the Laravel 6/7/8 era. Before you write a single line, check composer.json in vendor/laravelha/support for the illuminate/support constraint and confirm it resolves against your app's Laravel version. If you are on Laravel 10/11, composer require will usually refuse outright — that is the answer to the evaluation, and it is better to learn it in thirty seconds than after wiring call sites.

If it does install, look at, in this order:

1. composer.json → autoload.files. A files entry means the helpers are loaded on every request whether you use them or not; that is the whole package's cost model.
2. composer.json → extra.laravel.providers / extra.laravel.aliases. If absent, register the provider manually in bootstrap/providers.php.
3. src/ — the package is tiny enough to read end to end in ten minutes. Do that instead of trusting the README.

First use case: pick exactly one helper or trait you actually want, use it in one test file, and confirm it works. Do not refactor existing code to use the package's conventions — the conventions are the part most likely to diverge from your codebase and from future Laravel versions.

A realistic first-use flow:

// tinker or a scratch test
$provider = app(\LaravelHa\Support\...ServiceProvider::class); // confirm it resolved

Implementation Patterns

Use it as a reference, not a dependency. With zero dependents and an eight-star repo, the maintenance signal is weak. The highest-leverage pattern is to read src/, copy the two or three functions or traits you need into app/Support/ with an App\ namespace, and composer remove laravelha/support. You keep the utility, you drop an upgrade obligation, and you gain the ability to fix it when Laravel's API shifts.

If you do keep it, wrap it. Never call package helpers directly from controllers or Blade. Put a thin App\Support\* facade over the calls you use:

// app/Support/Format.php
final class Format
{
    public static function bytes(int $n): string
    {
        return \LaravelHa\Support\...::humanBytes($n); // the single call site
    }
}

When the package breaks on a framework upgrade — or when you decide to remove it — you change one file and your call sites are untouched. This is the single highest-value habit for a low-maintenance dependency.

Extend the base provider, don't fight it. If the package ships an abstract service provider, the intended pattern is subclassing it for your own packages: it likely centralises publishes(), mergeConfigFrom(), and registration ordering. Check that its boot()/register() are protected and the class is not final before you build on it; if it does boot-time work unconditionally, you inherit that cost in every provider that extends it.

Namespace your own helpers the same way it namespaces its. If the package registers global functions, it should guard them with if (! function_exists(...)). Mirror that guard in anything you add, or an composer dump-autoload will hand you a fatal redeclare error the day two packages ship a str_slug-style helper.

Test the behaviour, not the package. Your tests should assert on your wrapper's output. If the package supplies model traits, cover them with a factory-based test on your own model so a package upgrade that changes trait behaviour fails your suite rather than production.

Local vs production config. If the package ships a publishable config, publish it and commit it. Config that lives only in vendor/ is invisible to reviewers and silently changes under you on composer update.

Gotchas and Tips

• Global helper collision is the classic failure. Functions loaded via autoload.files are declared before your application boots. If Laravel itself (or another package) now defines the same name, you get Cannot redeclare. Grep src/ for function and check each one has a function_exists guard.
• Removed framework helpers are the other classic. Packages of this vintage often call array_get(), str_slug(), str_* helpers that were deprecated in Laravel 5.8 and removed in 6+. Run php -d error_reporting=E_ALL artisan about and exercise the code paths you use; the deprecation log surfaces these before they become fatal.
• Auto-discovery fails silently behind a cached manifest. If classes "don't exist" in a deployed environment but work locally, run php artisan package:discover and php artisan config:clear.
• composer require resolving is not compatibility. A caret constraint that spans ^6.0|^7.0|^8.0 will install on 6 but may still call APIs removed in 8. Read the constraint, then read the code.
• autoload.files has no lazy-loading escape hatch. Every request pays for parsing those functions, even a JSON API that never touches them. Small in absolute terms, but it is the reason to copy rather than depend if you only need one helper.
• Static properties leak into Octane and queue workers. If the package caches anything on a static property or a singleton-resolved instance, long-lived workers will serve stale values across requests. Check for static $ in src/; prefer copying the logic into a scoped binding over trying to reset vendor state from a listener.
• No changelog, no release notes, no 1.x history to diff. Combined with the 2020 release date, assume the package is dormant. Before adopting, check the issue tracker's open/closed ratio and the last commit date — a dormant package on a critical path is a fork commitment you make implicitly.
• Never patch vendor/. If you need behaviour changes, fork under your own namespace or copy the file. Edits under vendor/ are reverted on the next composer update and invisible to the next developer.
• Publishing is not upgrading. Anything you vendor:publish — config, migrations, stubs — is copied once and never updated. Since the upstream is dormant, this matters less, but note the published-asset list in your README so the next person knows what is yours and what is theirs.
• Removal path should be boring. For a package this size it should be: delete the wrapper class, composer remove, done. If you find yourself needing more than that, you have coupled too tightly and should back out before expanding call sites.