Support Laravel Package

Getting Started

Treat larva/support as a vendor utility layer, not a framework. With 1 star and 0 dependents, the first job is reading the source, not the README.

1. Install and inspect in one pass.

   composer require larva/support
   composer show larva/support          # version, requirements, autoload
   cat vendor/larva/support/composer.json
   

   Look specifically at:

   • autoload.files — means global helpers/constants are loaded on every request; these are your highest-value and highest-risk surface.
   • autoload.psr-4 — namespaced classes you can use directly.
   • extra.laravel.providers / aliases — whether auto-discovery is wired up.

2. Find the entry points first. In order:

   • src/*ServiceProvider.php — what it binds, registers, publishes, or macros.
   • Any helpers.php / functions.php — enumerate with grep -rn "^function " vendor/larva/support/src.
   • config/ — anything publishable (php artisan vendor:publish --provider="Larva\\Support\\...").
   • src/Concerns or src/Traits — the composable pieces you'll actually use on models/controllers.

3. Smoke-test before adopting. Open php artisan tinker and call one helper or instantiate one class. If it fails on your Laravel version, you've saved yourself a refactor:

   php artisan about
   composer show --tree larva/support
   

4. First real use case: inventory duplicated utility code in app/Support, app/Helpers, and model traits. Map each to a package equivalent. Anything with a clean match gets replaced; anything ambiguous stays — for a package this small, you adopt selectively, not wholesale.

Implementation Patterns

Wrap, don't sprinkle. Because the package is unproven, put a thin app-level seam in front of it:

// app/Support/Str.php
final class Str
{
    public static function slugify(string $v): string
    {
        return \Larva\Support\...::slug($v); // single call site to swap later
    }
}

This gives you one file to patch if the package is abandoned, and one place to add tests around behavior you depend on.

Use global helpers where they read naturally. If the package ships autoload.files helpers, they're intended for Blade and controllers. Prefer them in views ({{ some_helper($x) }}) and keep business logic in your own services — helpers are hard to mock and easy to overuse.

Compose traits into a base class, not individual models. If the package provides model/controller traits, apply them once:

abstract class BaseModel extends Model
{
    use \Larva\Support\Concerns\HasSomething;
}

Then every model inherits consistently, and removing the package is a one-line change.

Macro registration if the package is macroable. If it exposes Macroable classes, register extensions in your own AppServiceProvider::boot() rather than editing vendor code. Guard with if (method_exists(...)) so a version bump doesn't fatal.

Gradual migration workflow. Do it per-file with tests green: replace one call, run the suite, commit. Never do a package-wide codemod against a 0-dependent package on a Friday.

Contract tests as insurance. Write a small suite that pins the behavior you rely on:

it('slugifies as expected', function () {
    expect(some_package_helper('Hello World'))->toBe('hello-world');
});

When you upgrade, these fail loudly instead of silently changing output.

Pin the version. In composer.json, use "larva/support": "1.x-dev" or an exact tag rather than ^1.0 until you've validated one upgrade cycle. Commit composer.lock.

Gotchas and Tips

• Global function collisions. autoload.files helpers are defined unconditionally in many small packages. If the package redeclares something Laravel or another dependency already defines, you get a fatal Cannot redeclare. Check with grep -rn "function_exists" vendor/larva/support — a well-built package guards these; a 1-star package often doesn't.
• Auto-discovery may not fire. If classes aren't resolving, confirm extra.laravel.providers exists in the package's composer.json; otherwise register manually in config/app.php (Laravel 10-) or bootstrap/providers.php (Laravel 11+).
• Illuminate version constraints. Run composer show larva/support and check the illuminate/* requirements against your app. With 0 dependents, compatibility with recent Laravel majors is likely untested. If the constraint is loose (e.g. ^9.0|^10.0) but you're on 12, smoke-test before trusting it.
• Release date looks off. The listed release (2026-09-05) may be a mis-tag or future-dated tag. Verify with composer show larva/support --all and confirm the tag you install actually matches the code you inspected.
• No docs means reflection is your docs. When behavior is unclear:

  $r = new ReflectionClass(\Larva\Support\SomeClass::class);
  dump($r->getMethods(ReflectionMethod::IS_PUBLIC));
  

  Also dd() inside a helper to confirm it's the package's version and not a shadowed one.
• Stale autoload after inspection. If you edit vendor files while exploring, run composer dump-autoload and restart Octane/queue workers — opcache and preloaded files will otherwise serve the old code.
• Static analysis will complain. Untyped helpers and mixed returns generate PHPStan noise. Add a baseline entry for vendor/larva/support rather than suppressing globally, and type your wrapper layer.
• Extension points are probably config + container. Publish config first (vendor:publish), then check $this->app->bind(...) in the provider — if a class is bound to a contract, you can swap it via your own provider binding without forking.
• Bus factor is 1 star. Do not depend on this from packages you distribute, and for anything load-bearing, either vendor the two or three functions you need into app/Support or fork it under your org. The cost of copying 200 lines is lower than the cost of an abandoned dependency in your hot path.
• Debugging order: (1) composer show for version/requirements, (2) confirm provider loaded via php artisan about or app()->getLoadedProviders(), (3) confirm helper exists via function_exists(), (4) only then read logic. Most failures here are registration, not implementation.