Support Laravel Package

Getting Started

Install

composer require maxfactor/support

The package was last released in March 2020, so pin it explicitly and verify the constraint against your Laravel version before assuming it works on 8/9/10/11:

composer require "maxfactor/support:^1.0" --with-dependencies

Where to look first

1. composer.json — check the require block for the Laravel version range and extra.laravel.providers / aliases for auto-discovery.
2. src/ — support packages like this are usually a handful of files: a service provider, a helpers/functions file, and one or two classes (Collection macros, a Str/Arr extension, a facade).
3. README.md — expect it to be short; the source is the documentation.
4. Tests, if any — tests/ shows intended usage better than the README.

First use case

Once installed, confirm what actually got registered:

php artisan tinker

Then probe for the common entry points of a helper package:

// global helper functions
get_defined_functions()['user']; // grep for anything that looks package-prefixed

// collection macros
collect()->macroNames ?? null; // or try a suspected macro

If a service provider is registered, php artisan about (Laravel 9+) or php artisan route:list-style introspection won't reveal it — open src/*ServiceProvider.php and read register() and boot() directly. That is the fastest way to know whether you're getting helpers, macros, Blade directives, or validation rules.

Implementation Patterns

Because this is a low-traffic helper package (3 stars, no dependents), treat it as a lightweight utility layer rather than a framework extension. The realistic day-to-day patterns:

Global helpers in application code

If the provider loads a helpers.php, the functions are available everywhere. Use them where they read clearly, and keep a thin wrapper so you can swap the package out later:

// app/Support/helpers.php or a small class
function format_thing($value): string
{
    return \Maxfactor\Support\...::make($value)->toString();
}

Wrapping is the single most valuable pattern here — with no dependents and a 2020 release, you want a one-file seam to remove the dependency if it rots.

Collection macros

If the provider registers macros, they compose naturally with query results:

$users = User::all()->somePackageMacro();

Prefer this over calling package classes directly in controllers; it keeps the call site idiomatic Laravel.

Service provider overrides

If you need to change behavior, don't edit vendor code. Re-register your own binding in AppServiceProvider::register() after the package provider loads, or extend the package class:

$this->app->extend(
    \Maxfactor\Support\SomeClass::class,
    fn ($service, $app) => new \App\Support\CustomSomeClass($service)
);

Blade / validation integration

If boot() registers directives or rules, document them in your team's internal README immediately. Undocumented Blade directives are the number-one source of "why does this template work" confusion on small packages.

Testing

Add a smoke test that asserts the package's provider boots in your app — it catches Laravel-version breakage early:

public function test_support_package_boots(): void
{
    $this->assertTrue(class_exists(\Maxfactor\Support\ServiceProvider::class));
    // assert one helper or macro you actually rely on
    $this->assertTrue(function_exists('your_helper'));
}

Gotchas and Tips

• Laravel version drift is the main risk. A 2020 release predates Laravel 8's model factory changes and the 9/10 provider conventions. Check composer.json constraints first; if it says ^5.8|^6.0, you'll likely need --ignore-platform-reqs or a fork. Do not force it into a modern app without reading the source.
• Global helper collisions. Helper packages define functions in the global namespace. If another package (or your own app/helpers.php) defines the same name, you get a fatal Cannot redeclare. Grep vendor/ before adding a similarly named helper of your own.
• Auto-discovery may not be configured. If there's no extra.laravel.providers, nothing registers automatically — you must add the provider to config/app.php. Verify by checking whether a known macro/helper exists at runtime.
• Facades need aliases. If the package ships a facade without an alias entry, use the fully-qualified class or register the alias yourself in config/app.php.
• Config publishing. If a config/maxfactor.php (or similarly named) exists, run php artisan vendor:publish --provider="Maxfactor\Support\ServiceProvider" and commit the published file so config is explicit, not implicit default.
• No docs, no dependents, no recent releases. Budget time to read every source file — it's small. Write a short internal note listing exactly which helpers/macros you use, so upgrading or removing it later is mechanical.
• Debugging registration order. If behavior differs between php artisan and HTTP requests, it's usually a provider ordering issue. php artisan about or dumping $this->app->getLoadedProviders() from a route will show what's actually booted.
• Forking is cheap here. With MIT licensing and a tiny surface area, copying the two or three helpers you need into app/Support/ is often a better long-term call than carrying an unmaintained dependency — the extension point that matters most is your own wrapper layer.