Support Laravel Package

Getting Started

Because sebwite/support ships with no star history, no dependents, and no discoverable documentation, treat it as read-the-source-first, not composer require and go.

1. Clone and inspect before installing:

   composer require sebwite/support --no-scripts
   # then, before writing any code:
   ls -R vendor/sebwite/support/src
   cat vendor/sebwite/support/composer.json
   

   The composer.json autoload and providers entries tell you almost everything: whether this is a helper-function dump (files array), a set of base classes (psr-4), or a facade bundle (aliases).

2. Register the provider manually. It was authored for Laravel 5 (pre-5.5 conventions), so do not assume package discovery:

   // config/app.php
   'providers' => [
       // ...
       Sebwite\Support\SupportServiceProvider::class,
   ],
   'aliases' => [
       'Support' => Sebwite\Support\Facades\Support::class,
   ],
   

   Confirm the actual class name from src/ — the directory is the source of truth, not the package name.

3. Look at these three spots first, in order:

   • src/SupportServiceProvider.php — what it binds, publishes, and merges.
   • Any src/Helpers/ or src/helpers.php file — this is usually where a "support" package hides its real value (string/array/URL helpers).
   • config/ — whether configuration is publishable and what keys are expected.

4. First use case. The canonical reason to pull this in on a Laravel 5 app is to reuse the helper functions and base classes. After registering the provider, sanity-check one helper in php artisan tinker:

   >>> support_helper_name('foo')   // whatever the source exposes
   

   If it errors with "call to undefined function," the files autoload was not registered — check composer dump-autoload.

Decision gate: if the repository has no CHANGELOG, no LICENSE, and no tests, stop here and copy the handful of functions you actually need into your own app/Support/ namespace. A zero-adoption package is a maintenance liability, not a dependency.

Implementation Patterns

Assuming (as the source will confirm) a typical Laravel 5 support bundle, these are the patterns to adopt.

Helper functions as thin wrappers. Support packages usually expose global helpers that wrap static utility classes. Use them at the edges (controllers, Blade, commands) but keep domain code dependent on your own interfaces:

// Controller — fine
$slug = support_slugify($request->title);

// Domain service — prefer injecting the underlying class
public function __construct(private \Sebwite\Support\Str\Str $str) {}

Extending base classes rather than using them raw. If the package provides BaseModel, BaseController, or BaseRepository, subclass them in your app and never reference the vendor class directly elsewhere. That gives you a single seam to swap or patch:

namespace App\Models;

class BaseModel extends \Sebwite\Support\Models\BaseModel
{
    // your global model behaviour, UUIDs, etc.
}

Facade binding for testability. If a facade exists, resolve it via the container in tests so you can swap it:

Support::shouldReceive('format')->andReturn('ok');

Better: bind a contract in your own service provider and let the package be the default implementation. That way an abandoned package can be replaced in one binding.

Provider chaining for config merge. Publish config and merge your overrides in AppServiceProvider::register():

$this->mergeConfigFrom(base_path('config/support.php'), 'support');

This keeps package defaults intact while letting local environment tweaks win.

Composition over inheritance for traits. If the package ships traits (e.g., a Sluggable or Presentable trait), apply them on models but keep the trait-backed columns migrated in your own migrations — never rely on the package to publish migrations, because an unmaintained package often ships stale ones.

Wrap in a small adapter. For anything beyond one-off helpers, create app/Support/PackageAdapter.php that composes the vendor classes. Day-to-day usage then flows through your adapter, and the "what happens if this package disappears" question answers itself.

Gotchas and Tips

• Laravel 5 only. The package was built for Laravel 5.x. On Laravel 6+ you will hit missing Illuminate\Support\* signatures, Str::/Arr:: helper removals, and helpers.php collisions (Laravel 5.5 shipped its own str_*/array_* helpers that often conflict). Check the composer.json illuminate/support constraint before installing.

• Global helper collisions are the #1 failure. If the package defines a function that Laravel or another package already defines, you get a fatal "cannot redeclare." Grep the source:

  grep -rE "function [a-z_]+\(" vendor/sebwite/support/src
  

  Cross-reference against your other packages before relying on it.

• Autoload files must be dumped. Helpers won't appear until composer dump-autoload runs after install. In CI, ensure --no-dev --optimize-autoloader still includes the files entry.

• Config publish is one-way. php artisan vendor:publish copies defaults; later package updates will not update your published copy. Diff config/support.php against the vendor version after any composer update.

• No discovery means silent no-ops. If you forget to add the provider in config/app.php, facades resolve to null and helpers may still work (because files autoload is independent of the provider). This asymmetry makes bugs look like logic errors — always verify the provider is registered first.

• Debugging tip: php artisan tinker and dd(class_exists(\Sebwite\Support\Facades\Support::class)) confirms registration in one line. php artisan route:list failing with "target class does not exist" is a near-certain sign the provider is missing.

• Extension points are wherever the classes are protected/non-final. Run grep -r "final class\|private function" vendor/sebwite/support/src — anything marked final or private is not an extension point and should be wrapped by your adapter instead.

• Pin the version. With zero dependents, there is no community pressure to keep releases backwards-compatible. Use an exact version constraint ("sebwite/support": "1.2.3") and commit composer.lock, or fork the repo into your VCS and reference it as a vcs repository so you control the tag you deploy.

• Vendor it if you depend on it long-term. Given the abandoned signal, the pragmatic exit is: cp -r vendor/sebwite/support/src app/Support/Sebwite, rename the namespace, and delete the composer dependency. One afternoon of work now beats an emergency rewrite later.