Support Laravel Package

Getting Started

laradic/support is a grab-bag of Laravel "support extras" — additional helpers, base classes, and small utilities layered on top of illuminate/support. It is not a framework, so onboarding is mostly about discovering what's actually in it before you build on it.

1. Install (check the constraint first — this package tracks Laravel versions closely):

   composer require laradic/support
   

2. Look at the source before the docs. With 7 stars and no dependents there is effectively no community documentation or StackOverflow corpus. The authoritative reference is src/ in the repo:

   ls vendor/laradic/support/src
   cat vendor/laradic/support/composer.json   # autoload map, laravel/illuminate constraints, php version
   

   Pay attention to the autoload.files entry — if the package registers global helper functions, that file is your fastest map of its public surface.

3. Check for a service provider. If composer.json has a extra.laravel.providers block, Laravel auto-discovers it. If not, register manually in bootstrap/providers.php (Laravel 11+) or config/app.php (10 and below):

   'providers' => [
       Laradic\Support\ServiceProvider::class,
   ],
   

   Then look for a publishable config: php artisan vendor:publish --provider="Laradic\Support\ServiceProvider".

4. First use case. Don't adopt it wholesale. Pick one utility you need — typically a string/array helper, a path helper, or a ServiceProvider base class — use it in a single service, and verify behaviour against Laravel's native equivalent. Confirm the win before spreading it through the codebase.

5. Sanity check the license. composer.json reports NOASSERTION, meaning the license could not be machine-detected. Open the LICENSE file in the repo root before you ship this to a client or a commercial product.

Implementation Patterns

Treat it as a helper namespace, not a dependency. The healthy pattern is to call its classes directly at the point of use and never let them leak into public signatures:

use Laradic\Support\Str;   // verify the actual FQCN in src/ first

final class SlugGenerator
{
    public function make(string $title): string
    {
        return Str::slug($title); // swap for \Illuminate\Support\Str and it still works
    }
}

That keeps the package replaceable — important for a package with near-zero adoption.

Wrapping helpers behind your own façade. Because global helper functions are hard to mock, wrap any function-based helper you depend on in a small injectable class. One class per helper keeps the coupling visible and testable.

Extending base classes when they exist. Packages in this family typically ship an opinionated ServiceProvider (with helpers for config, migrations, routes, translations) and sometimes a Facade. If src/ contains one, extend it only in new packages you author — do not retrofit it onto existing providers, since you'd inherit behaviour you haven't audited:

use Laradic\Support\ServiceProvider;

class MyPackageServiceProvider extends ServiceProvider
{
    protected function boot(): void
    {
        // check the parent's hook names — may be boot(), register(), or neither
    }
}

Config-driven integration. If the provider merges config, publish it and commit the published file rather than relying on package defaults. With an unmaintained upstream, defaults can change or disappear on a minor bump; a committed config file pins your assumptions.

Composer constraints as the real integration contract. Pin explicitly and let Composer resolve against your Laravel version:

"laradic/support": "^2.0"

Run composer why-not laradic/support when a Laravel upgrade fails — this package's illuminate/* range is the most likely blocker, and it's typically the first thing to abandon during an upgrade.

Use it as a reference implementation. With 7 stars and 0 dependents, the highest-value pattern is reading it: its base classes and helpers are a decent study of idiomatic Laravel package structure. Copy the pattern into your own code under your own license rather than taking the runtime dependency.

Gotchas and Tips

License is unresolved. NOASSERTION from Composer means you must read LICENSE manually. For anything commercial or redistributed, get an explicit answer before adoption — an ambiguous license on a 7-star package is a legal question, not a technical one.

Treat maintenance as a risk, not a feature. 7 stars, 0 dependents, and a score profile dominated by "opportunity" means: no bug-report pressure, no third-party tutorials, no one else hitting your edge cases. Budget for the possibility that you are the maintainer of your fork. If you depend on it, fork it under your own org and point Composer at the fork via a vcs repository — this is the standard hedge for low-adoption packages.

Global helper collisions. If autoload.files loads helper functions, check for names that clash with Laravel's own (str(), array_wrap(), path_join()) or with other packages. A redeclaration throws a fatal at boot, not a catchable exception. Grep the loaded file:

grep -rn "function " vendor/laradic/support/src/ | grep -v "::"

Auto-discovery surprises. A provider registered via extra.laravel.providers can silently add config merges, view namespaces, and macro registrations on every request. Use php artisan about (Laravel 9+) or dump app()->getLoadedProviders() to confirm what it actually registered, then decide whether to move it to dont-discover in composer.json.

Debugging failures. With no documentation, work from the stack trace into vendor/laradic/support/src directly, and use composer dump-autoload -o after any edit. If helpers appear missing, it's almost always a stale autoload files map — composer dump-autoload fixes it.

Version skew across Laravel majors. Confirm the package's illuminate/support constraint covers your framework version before writing code against it. If it only supports an older major, you'll be fighting deprecations (Str method removals, container signature changes) that nobody upstream has fixed yet.

Extension points are whatever src/ exposes. Without a documented API there is no stability promise — anything public is fair game to change. Constrain to ^x.y, commit composer.lock, and re-read the diff on every upgrade rather than trusting semver.

Testing. Never rely on this package's own helpers inside assertions. Assert against native Laravel/PHP behaviour so a package regression can't make a broken test pass.