Getting Started

stinger-soft/php-commons is not a Laravel package. There is no service provider, facade, config file, or publishable asset — it is a plain PHP utility library ("some common PHP methods") that happens to be installable via Composer alongside Laravel. Treat it like any PSR-4 dependency, not like a framework extension.

Minimal steps:

Audit before installing. With 0 stars and 0 dependents, read the source first:
```
git clone https://github.com/Stinger-Soft/PhpCommons /tmp/php-commons
cat /tmp/php-commons/composer.json   # PHP version constraint + autoload map
ls -R /tmp/php-commons/src
```
Confirm the require block's php constraint is satisfied by your app (Laravel 10/11 typically run PHP 8.1+), and note whether autoloading is PSR-4 ("StingerSoft\\Commons\\": "src/") or files-based (global functions).
Install if, and only if, it fills a real gap:
```
composer require stinger-soft/php-commons
```
Since there's no Laravel auto-discovery, nothing else is required — no config/app.php edit.
Where to look first: the README (often thin for small libs), then src/ for the actual class list. Map each public static method against what Laravel already gives you (Str::, Arr::, Number::, Collection, Carbon). Anything already covered by the framework is dead weight in your dependency tree.
First use case: the highest-value scenario is a legacy or non-Laravel codebase where the same isNullOrEmpty()-style helpers have been copy-pasted across controllers/commands. Import the class, call it statically, delete the duplicates:
```
use StingerSoft\Commons\StringUtils; // verify exact namespace in src/

if (StringUtils::isBlank($request->input('nickname'))) {
    // ...
}
```
Because it's framework-agnostic, it works identically in an Artisan command, a queued job, a Blade view, or a standalone script — which is the one thing it has over a app/Support/helpers.php file.

Honest recommendation for most Laravel teams: skip the dependency and copy the 2–4 methods you actually need into app/Support/. Zero-supply-chain-risk beats a zero-star transitive dependency.

Implementation Patterns

Pattern 1 — Direct static calls (the intended usage). The library exposes static utility methods. Use it inline where a framework helper would otherwise force you to reach for a facade in code that should stay framework-free (domain objects, value objects, DTO casts):

final class Money
{
    public function __construct(public readonly int $cents) {}

    public static function fromString(string $value): self
    {
        // helper stays out of the Eloquent/HTTP layer
        $value = \StingerSoft\Commons\StringUtils::trimAll($value);
        return new self((int) round((float) $value * 100));
    }
}

Pattern 2 — Thin wrapper service (recommended for anything beyond a one-off). Never let the raw namespace leak across your codebase. Bind a small interface so you can swap implementations or drop the dependency later without a grep-and-replace:

// app/Support/Contracts/Text.php
interface Text
{
    public function isBlank(?string $value): bool;
    public function slugify(string $value): string;
}

// app/Support/CommonsText.php
final class CommonsText implements Text
{
    public function isBlank(?string $value): bool
    {
        return \StingerSoft\Commons\StringUtils::isBlank($value);
    }

    public function slugify(string $value): string
    {
        return \StingerSoft\Commons\StringUtils::slugify($value);
    }
}

// app/Providers/AppServiceProvider.php
$this->app->singleton(\App\Support\Contracts\Text::class, \App\Support\CommonsText::class);

Now app(Text::class) is injectable into controllers, jobs, and Blade components alike.

Pattern 3 — Composition, not replacement. Where Laravel already wins, stay with Laravel. Str::slug(), Str::of()->trim(), Arr::get(), and blank()/filled() cover the vast majority of "common PHP methods." Reserve this library for the genuinely missing pieces, e.g. a specific string-normalization or array-diff routine that Arr doesn't expose. Mixing both is fine:

$slug = Str::slug($title);                       // framework
$clean = StringUtils::normalizeWhitespace($b);   // library, if it exists in src/

Pattern 4 — Non-HTTP contexts. This is where the package earns its keep over a facade: queued jobs, Artisan commands, and unit tests that deliberately boot no application container. There's no config/app.php entry to forget and no facade root to set up.

Pattern 5 — Evaluation harness. Before adopting, write one test that exercises every method you intend to use, pinning the behavior you're relying on. If the package is later abandoned (likely at 0 stars), that test file is your spec for reimplementing it locally:

it('matches expected commons behavior', function () {
    expect(StringUtils::isBlank('  '))->toBeTrue();
    expect(StringUtils::isBlank('x'))->toBeFalse();
});

Gotchas and Tips

No Laravel integration — and that's deliberate. Don't hunt for a service provider, config key, or .env variable. There is nothing to publish. If you expected php artisan vendor:publish, you want a different package.
Global-function autoloading is the biggest risk. If composer.json uses an "autoload": { "files": [...] } entry, those functions are defined in the global namespace and may collide with your own app/Support/helpers.php or another dependency. Check the autoload map first; a cannot redeclare function fatal at boot is the classic symptom.
Zero dependents means unvetted. No downstream project has battle-tested this against modern PHP. Pin it exactly ("stinger-soft/php-commons": "1.0.0" — no caret) or commit the source into your repo, because composer update on an unmaintained package is a silent-breakage vector.
PHP version constraint drift. A small library authored years ago may declare php: ^7.x, which Composer will honor under Laravel 11's PHP 8.2+ and refuse to install — or worse, install and emit deprecation notices. composer why-not stinger-soft/php-commons is your first debugging command when install fails.
Static helpers are untestable by design. You can't mock a static call. That is precisely the reason for Pattern 2's wrapper interface — inject the contract, not the class, and your tests stay Mockery-friendly.
Debugging: the methods are pure functions, so the fastest path is a one-liner Tinker session rather than a debugger:
```
php artisan tinker --execute="dump(\StingerSoft\Commons\StringUtils::isBlank(' '));"
```
If the class isn't found, composer dump-autoload and verify the namespace against src/ — small libraries frequently have stale READMEs with renamed classes.
Extension points are effectively none. There's no config, no driver, no interface to implement. The real extension mechanism is the wrapper in Pattern 2, or forking the repo and vendoring the handful of methods you use into app/Support/ — which, for a package at 0 stars, is usually the right call.
Watch for hidden I/O or locale assumptions. Generic string helpers often bake in setlocale-dependent behavior or mb_* fallbacks. If any method produces locale-sensitive output (case folding, sorting, transliteration), verify it under your app's APP_LOCALE before shipping it into a user-facing path.
License is clean. Apache-2.0 permits commercial use and modification; you may fork and vendored-copy the methods with attribution. If you do copy, keep the license header comment so compliance stays trivial.

Php Commons Laravel Package

Getting Started

Implementation Patterns

Gotchas and Tips