Support Laravel Package

Getting Started

Install and confirm autoloading

composer require padosoft/support

Because the package is zero-dependency and function-based, the critical first step is checking how the helpers are exposed. Open vendor/padosoft/support/composer.json and look at the autoload block — helper packages usually ship functions via "files": [...] or a namespaced class. Then inspect vendor/padosoft/support/src/ to see whether functions are global (padosoft_support_*), namespaced (Padosoft\Support\...), or exposed through a Support facade/class.

Where to look first

1. composer.json → autoload.files / autoload.psr-4 — tells you if functions are globally loaded.
2. src/ directory listing — usually grouped by concern (string.php, array.php, file.php, env.php, etc.).
3. README.md and any docs/ — most helper packages list the function catalog there, but sparse READMEs are common; the source is the source of truth.
4. tests/ — the fastest way to see intended usage and edge cases for each helper.

First use case

Replace ad-hoc utility methods scattered across your codebase:

// Instead of hand-rolling in every service:
if (is_json($payload)) { ... }
$slug = str_slug_clean($title);

Start by auditing your own code for repeated str_*, array_*, and file/string cleanup logic, then map those to the package's equivalents. The value is consistency and a single tested implementation across packages.

Implementation Patterns

Direct function calls (global or namespaced)

If helpers are globally autoloaded, call them directly. If they live under a namespace, import explicitly:

use function Padosoft\Support\str_...;

Use function_exists() guards only when writing code that must run in environments where the package may be absent (e.g., a shared library that lists it as suggest rather than require).

Wrapping in your own adapter

For long-lived projects, wrap third-party helpers in a thin internal class so you're not coupled to the package's naming:

namespace App\Support;

final class Str
{
    public static function slug(string $value): string
    {
        return \padosoft_...($value); // single point of change
    }
}

This is especially worth doing because helper packages can rename or drop functions between major versions, and global functions are hard to refactor with IDE tooling.

Laravel integration

For Laravel projects, either register a small service provider that requires the function files, or use the package's own provider if one exists. If the package only ships functions, add the file to composer.json autoload.files of your app — but prefer the package's own autoload so upgrades stay clean.

Foundational dependency for your own packages

The package is explicitly designed as a foundation. When you build your own package on top, pin a compatible range and use the helpers rather than reimplementing — but keep the dependency in require, not require-dev, and be mindful that global functions in a dependency are a compatibility surface for downstream consumers.

Testing pattern

Because these are pure functions, they're trivial to unit test. In your own tests, assert behavior of the wrapper rather than the package directly, so swapping implementations later doesn't break tests:

it('slugs titles consistently', function () {
    expect(Str::slug('Ciao Mondo!'))->toBe('ciao-mondo');
});

Gotchas and Tips

Global namespace collisions. The biggest risk with agnostic helper collections is function names squatting in the global namespace. A function like is_json() or array_get() may collide with Laravel's own array_get (pre-5.8) or another package. Run composer dump-autoload -o and watch for "Cannot redeclare function" fatals; if you hit one, audit which package loads first.

Autoload ordering. Functions autoloaded via "files" are loaded at composer bootstrap. If your app defines the same function after composer's autoloader, you'll fatal. Never shadow package functions with your own — prefix your own (app_is_json) or wrap instead.

No IDE autocompletion. Global functions from an autoloaded file aren't discoverable by PHPStorm or Psalm/PHPStan without stubs. Generate a stub file or, more practically, wrap them in a class (see adapter pattern). This alone is a strong argument for wrapping in production codebases.

Version pinning. With a last release dated 2026-05-28 and a small star count (51), treat the project as lightly maintained. Pin to a specific minor ("padosoft/support": "~1.2") and review the changelog before upgrades. Do not use dev-master in anything that ships.

Documentation is thin. Assume the README is incomplete. Grep the source for function (globally) or public static function and build your own index. Check the tests/ folder for parameter edge cases — that's where the real contract lives.

Debugging helper behavior. Since functions can return loosely-typed values (mixed, arrays, null on failure), add strict type checks at your call sites. Use var_dump/xdebug freely — there's no state, no container, nothing to configure, so behavior is deterministic and easy to isolate.

Extension points are limited. A zero-dependency function library generally has no config file, no service container bindings, and no events. If you need configurability (e.g., custom slug options), wrap the function and add your own options rather than expecting the package to provide them. Forking is often the realistic answer for a single-file helper set — the MIT license permits it, and the codebase is small enough to vendor-inline if maintenance stalls.