Support Laravel Package

Getting Started

1. Install via Composer: composer require kodicomponents/support. The package is a generic "support" library — expect helper classes, traits, contracts, and possibly a base service provider rather than opinionated features. There is no scaffold command promised; verify what actually ships.

2. Inspect the installed code first. Before wiring anything, run:

   composer show kodicomponents/support
   ls vendor/kodicomponents/support/src
   

   Look for src/helpers.php, src/SupportServiceProvider.php, and any Contracts/ or Traits/ directories. Since the package is lightly used (≈10 stars) and last released in September 2020, reading the source is more reliable than assuming documentation exists.

3. Check auto-discovery. If a SupportServiceProvider exists, Laravel will register it automatically. If it doesn't appear in composer show, add it manually to config/app.php:

   'providers' => [
       KodiComponents\Support\SupportServiceProvider::class,
   ],
   

4. Publish any config (only if the package exposes one):

   php artisan vendor:publish --provider="KodiComponents\Support\SupportServiceProvider"
   

5. First use case: the most common use of a "support" package is as a base layer — extending a provided base model/controller or pulling in a trait like string/array helpers, HasMeta, or sluggable behavior. Pick the single trait or helper you actually need and apply it to one model or controller before spreading usage.

First action for a 2020-era package: confirm it installs cleanly on your Laravel/PHP version before writing any code against it. See Gotchas.

Implementation Patterns

Trait composition on models.

use KodiComponents\Support\Traits\HasSomething; // verify actual name

class Post extends Model
{
    use HasSomething;
}

Treat traits as the primary integration surface. Apply one at a time and run the related test/model operation immediately.

Extending provided base classes. If the package ships BaseModel or BaseController, prefer extending those only when you gain real behavior. For a thin support library, composition (traits) usually ages better than inheritance, especially across Laravel majors.

Helper functions. If a helpers.php is autoloaded via the package's composer.json, the functions are globally available after composer dump-autoload. Wrap them in your own service or helper class so you have a single seam to swap if the package is abandoned:

class Text
{
    public static function slug(string $value): string
    {
        return kodi_slug($value); // wraps the vendor helper
    }
}

Contracts for testability. If contracts/interfaces are provided, bind them in a service provider and inject them rather than calling static helpers. This makes it easy to replace the package later:

$this->app->bind(
    \KodiComponents\Support\Contracts\Foo::class,
    \App\Support\FooAdapter::class
);

Config-driven behavior. Any config keys from the published file should be overridden in config/kodicomponents-support.php (or via .env) rather than mutated at runtime. Read defaults inside your own service providers so config caching is safe.

Integration tip — isolate the boundary. Because the package is low-adoption and unmaintained, introduce a thin app-level adapter layer around every class/trait/function you consume. That gives you a mechanical migration path if you later fork or drop the dependency.

Testing. Write a small test that exercises the exact helper/trait behavior you rely on. This doubles as a compatibility canary when you upgrade Laravel or PHP.

Gotchas and Tips

• Laravel/PHP compatibility is the primary risk. A September 2020 release predates Laravel 9, 10, and 11 and modern PHP 8.x features. Install with --dry-run first and check composer why-not kodicomponents/support if it fails. Expect to add "minimum-stability" or a replace/fork if you must use it on newer Laravel.

• Abandonment signal. 10 stars and a 0.28 quality score means minimal community coverage. Assume no fixes will land. Fork it into your org (composer require yourorg/support) if you depend on it in production.

• Auto-discovery vs. manual registration. Older packages sometimes still list the provider in config/app.php and rely on discovery; registering twice can cause subtle duplicate-binding bugs. Register in exactly one place.

• Static helper pollution. Global helper functions loaded via autoload.files cannot be namespaced away. If you have naming collisions (common with other support packages that also define str_* or array_*), wrap them immediately or you'll get fatal "cannot redeclare function" errors.

• Config cache staleness. After changing any config, run php artisan config:clear (or config:cache in deploy). Traits and helpers that read config at boot time will otherwise run with stale values.

• Debugging missing classes/traits:

  composer dump-autoload -o
  php artisan clear-compiled
  

  Then confirm the namespace in the class file matches what you imported — a mismatch is common in lightly maintained packages where src/ structure drifted from the published namespace.

• Extension points. Look for Contracts/ and any Illuminate\Support\Manager-based subclasses before forking — they're the intended seam for swapping implementations. Override via container bindings rather than modifying vendor code.

• Lockfile pinning. Since there's been no release since 2020, pin the exact version in composer.json ("kodicomponents/support": "1.0.*" or the actual tag) so a future yanked/edited tag doesn't silently change your build.

• Vendor coupling check. Before adopting, grep your codebase after integration for KodiComponents\ usages. If the count is high, replace the dependency with in-house equivalents now — the cost only grows.