Support Laravel Package

Getting Started

1. Install and pin it.

   composer require consoletvs/support:^1.0
   

   Because the last release was 2021, pin the major/minor explicitly in composer.json rather than floating. Commit composer.lock.

2. Locate the entry points first. Open the installed package under vendor/consoletvs/support/ and read, in this order:

   • composer.json — check autoload (is it PSR-4 classes, or files with global helpers?), require (PHP/Laravel constraints), and whether a providers/aliases entry exists.
   • src/ — identify whether you are consuming static helper classes, traits, or global functions.
   • README.md — the canonical usage examples for that release.

3. Confirm service-provider discovery. If a provider is listed under extra.laravel.providers, it is auto-discovered. If not, add it to config/app.php only if the source shows registration is actually required (many support libraries are pure static helpers and need none).

4. Smoke-test before adopting. In php artisan tinker, call one representative helper from the package and verify output. This validates autoloading, PHP version compatibility, and namespace assumptions in under a minute.

5. First real use case: formatting values at the edges of your app — string casing/truncation in Blade, number shortening in API resources, or array normalization in form requests. Treat it as a utility belt, not framework infrastructure.

Implementation Patterns

Wrap, don't scatter. The highest-leverage pattern with a low-maintenance support library is to consume it behind your own boundary:

namespace App\Support;

use ConsoleTVs\Support\...; // whichever helper you actually use

final class Format
{
    public static function short(mixed $value): string
    {
        return /* package helper call */;
    }
}

This gives you one file to patch if the package is abandoned, and keeps vendor namespaces out of controllers and Blade.

Use in Blade for presentation only. Helpers that format numbers, strings, or dates are ideal for view-layer output. Do not put business logic behind them.

Normalize at input boundaries. If the package offers array/string sanitizers, apply them in FormRequests or DTO constructors so the rest of the app receives consistent shapes.

Prefer Laravel native helpers when they overlap. Str::, Arr::, Number::, and Carbon cover most of what a 2021 support library provides. Use the package only where it adds something Laravel does not (e.g., a specific shortening, humanizing, or collection macro). Document why in a short comment.

Test your wrapper, not the vendor. Write unit tests against App\Support\Format, with a couple of cases that lock in expected outputs. If the package ever changes or is forked, tests tell you immediately.

Fork-and-vendor if usage grows. For a package with 27 stars and no releases since 2021, the moment you rely on more than one or two helpers, copy those helpers into app/Support/ (with license attribution) and drop the dependency. This is the most common long-term pattern for small utility packages.

Gotchas and Tips

• Maintenance risk is the headline. Last release 2021, low star count. Audit the code you actually call; do not assume Laravel 10/11 compatibility. Check composer.json PHP constraints and run your test suite on your target PHP version.

• Global function collisions. If the package registers files autoload with global helpers, names can clash with Laravel's or with your own. Inspect composer.json autoload.files before installing into a mature app; Laravel's helpers often already exist (str_contains, str_limit predecessors, etc.).

• Static helpers are hard to mock. If you find yourself wanting to mock a package helper in tests, that is the signal to route it through your wrapper or replace it with native Laravel code.

• Namespace drift across versions. Without a maintained changelog, verify the exact namespace in src/ rather than trusting README examples or blog posts — they may reference a different major.

• No config likely exists. Do not run vendor:publish blindly; check for a config/ directory first. A support library usually has none, and a failed publish just adds noise.

• Debugging tip: if a helper returns unexpected types (e.g., null vs '', or int vs string), dump the raw return in tinker and add a strict-typed wrapper with declare(strict_types=1). Loose return types are common in older utility code.

• Extension point is the source, not the API. With no active maintainer, extend by copying the specific helper into app/Support/ under MIT attribution. This is safer than subclassing or monkey-patching a static class, and it removes a dependency from your supply chain.

• Composer hygiene: add the package to your composer.json require with an exact constraint (1.x.y) and rely on composer.lock for reproducibility. Do not use ^ on an unmaintained package.

• Security review: read every function you intend to call. Utility libraries sometimes contain file/string helpers with edge cases (path handling, unserialize, regex) that matter if you pass user input. Restrict usage to trusted, internal data.