Lara Support Laravel Package

Getting Started

Start by installing and inspecting, not by reading docs — this package ships without meaningful public documentation, so the source is the documentation.

composer require omnicode/lara-support

Then, before writing a single line of application code:

1. Open vendor/omnicode/lara-support/composer.json. Look at three keys: require (which Laravel/Illuminate versions it targets), autoload.files (helpers that get loaded globally on every request), and extra.laravel.providers (whether it auto-registers).
2. Open vendor/omnicode/lara-support/src/. List the top-level directories. Typical "support" packages organise into Helpers/, Macros/, Traits/, Providers/, Facades/, and sometimes config/.
3. Find the service provider and read register() and boot(). This tells you everything the package actually does — macros registered on Collection/Str, singletons bound to the container, Blade directives, migrations, or config merges.
4. Dump the container bindings in Tinker to confirm what is live:

php artisan tinker
>>> app()->getLoadedProviders()['Omnicode\LaraSupport\...ServiceProvider'] ?? null
>>> collect(app()->getBindings())->keys()->filter(fn($k) => str_contains($k, 'omnicode'));

First real use case: treat it as a grab-bag of Laravel ergonomics — string/array helpers, Eloquent traits, or Collection macros — and cherry-pick only what you need. Run one helper or macro inside php artisan tinker to confirm it resolves, then wire it into a single feature branch before broadening use.

Implementation Patterns

Macro consumption. If boot() calls Collection::macro(...) or Str::macro(...), use macros like native API once the provider is registered. Keep a tests/Feature/SupportMacrosTest.php that asserts each macro you depend on behaves as expected — this is your regression net when the vendor package moves.

Trait adoption on models. Packages of this shape often ship traits (e.g. UUID keys, slugging on save, soft-delete helpers). Apply them one model at a time:

use Omnicode\LaraSupport\Traits\...; // verify exact FQCN in vendor/src/Traits

class Post extends Model
{
    use Sluggable; // example only — confirm name in source
}

Helper wrapping. If helpers are autoloaded via autoload.files, they are global functions and cannot be namespaced away. Wrap them in your own thin service so you can swap or stub them:

final class Support
{
    public static function slug(string $value): string
    {
        return support_slug_helper($value); // your alias for the vendor helper
    }
}

This gives you a seam for testing and a single place to change if the package is abandoned.

Config publishing. If config/lara-support.php exists, publish it and commit it — never rely on package defaults in production:

php artisan vendor:publish --provider="Omnicode\LaraSupport\...ServiceProvider" --tag=config

Isolation provider. In anything longer-lived than a prototype, register the package's providers from your own AppServiceProvider or a dedicated SupportPackageProvider, so auto-discovery is explicit and auditable.

Integration with the rest of the stack. Prefer using the package inside your own repositories/services rather than scattering helpers through controllers. For macros on Collection/Str, constrain use to a few layers so a future removal is a mechanical find-and-replace.

Gotchas and Tips

• Zero social proof. No stars, no dependents, no documentation. Treat every method as unaudited code: read it before trusting it with money, auth, or PII, and pin the version exactly ("omnicode/lara-support": "1.0.0", not ^1.0).
• Global helper pollution. autoload.files helpers can collide with framework helpers or other packages. Grep your vendor/ for duplicate function names if you see Cannot redeclare.
• Auto-discovery drift. If the package targets an older Laravel, extra.laravel.providers may not be honoured in newer majors, or vice versa. Check composer.json require against your Laravel version before upgrading.
• Config cache. After changing published config, always php artisan config:clear. Macro registrations inside boot() are not affected by config cache, but conditional registration (e.g. if (config(...))) is — a stale cache silently disables them.
• Macro name collisions. Laravel's own Collection macros and other packages may register the same name; the last boot wins. Assert macro existence and output in tests rather than assuming.
• No vendor tests to copy from. Write your own. For each helper you adopt, add one happy-path and one edge-case test. This is the only safety net you get.
• Extension points are limited. Without documented contracts, avoid subclassing the package's classes. Compose around them via your own wrappers instead — safer across upgrades and easier to remove.
• Debugging tips. php artisan about won't list the package; use composer show omnicode/lara-support and reflection (new ReflectionClass(...)) to enumerate public methods when the source layout is unclear. For macro bugs, Collection::hasMacro('name') in Tinker confirms registration before you chase usage bugs.
• Exit strategy. Because the package is unmaintained-looking, keep adoption shallow: a wrapper class and a handful of tests mean a two-hour removal if it goes stale.