Laravel Support Laravel Package

Getting Started

The package is a grab-bag of small traits and helpers the DragonCode author extracts from his own ecosystem (Laravel-DTO, Laravel-WhichColor, etc.). There is no facade and no opinionated API surface — the value is almost entirely in the src/Concerns directory. Treat it as "copy-in ideas with a Composer autoloader," not as a framework.

Install:

composer require dragon-code/laravel-support

Laravel picks up the service provider via package discovery. Lumen does not — register it manually in bootstrap/app.php:

$app->register(DragonCode\LaravelSupport\LaravelSupportServiceProvider::class);

Pin a minor version. 3.9.0 is the first release with Laravel 13 support and the first in a while with visible maintenance activity (see Gotchas). "dragon-code/laravel-support": "^3.9" is a safer floor than ^3.0.

Look here first, in this order:

1. vendor/dragon-code/laravel-support/src/Concerns/ — this is the real product. Skim the trait names before reading any docs; the README is thin and the source is the specification.
2. The composer.json require block — it tells you the minimum PHP and Laravel versions you are pinned to. As of 3.9.0 the ceiling now reaches Laravel 13.
3. CHANGELOG.md — this author keeps a readable one, and it is the fastest way to see what actually changed between minor versions. Read it literally: 3.9.0 is a compatibility release, not a feature release.

A reliable discovery command, since trait names are not documented anywhere else:

grep -rn "^trait \|^abstract class \|^class " vendor/dragon-code/laravel-support/src | sort

First real use case: you are writing your own small Laravel package and you are about to write the fourth copy of "publish the config file, load the migrations, register the translations" in a service provider. The service-provider concerns in this package exist precisely to collapse that boilerplate:

use DragonCode\LaravelSupport\Concerns\ServiceProvider\HasConfig;
use DragonCode\LaravelSupport\Concerns\ServiceProvider\HasMigration;
use Illuminate\Support\ServiceProvider;

class MyPackageServiceProvider extends ServiceProvider
{
    use HasConfig;
    use HasMigration;

    protected string $package = 'my-package'; // verify the exact expected property name in the trait source
}

If you are not writing packages, the honest first use case is smaller: pull in the one or two Concerns\Support\* traits you would otherwise hand-roll (environment checks, cache-key helpers) and skip the rest.

Implementation Patterns

Pattern 1 — package scaffold provider. The dominant pattern. Each concern does one publishing concern and expects the host provider to supply a package-name property and, usually, a __DIR__-relative path. Read the trait body first; most are 30–60 lines and will tell you exactly which abstract methods/properties you must define. Typical shape:

class MyPackageServiceProvider extends ServiceProvider
{
    use HasConfig;        // mergeConfigFrom + publishes config/{package}.php
    use HasTranslations;  // loadTranslationsFrom + publishes lang/
    use HasMigration;     // loadMigrationsFrom + publishes database/migrations
    use HasRoutes;        // loads routes/ if present

    public function register(): void
    {
        $this->mergeConfiguration(); // name varies — check the trait
    }

    public function boot(): void
    {
        $this->publishConfiguration();
        $this->publishMigrations();
    }
}

Do not assume the method names above; the whole point of the exercise is to open the trait and read them. Copy the method names verbatim from the source.

Pattern 2 — compose concerns into app-level classes. Where the package exposes runtime helpers (cache/array/environment style traits), use them via use inside your own class rather than as a global helper. This keeps the dependency visible and greppable:

final class ReportBuilder
{
    use \DragonCode\LaravelSupport\Concerns\Support\SomeHelper;
}

That explicitness matters when you later want to drop the package — a trait use is a single-line removal, a global helper function is a hunt.

Pattern 3 — the "vendor-publish smoke test." After wiring a provider with these traits, immediately verify the published surface:

php artisan vendor:publish --provider="App\Providers\MyPackageServiceProvider"
php artisan vendor:publish --provider="App\Providers\MyPackageServiceProvider" --list

If the config and migrations land, your property names are right. This is a faster feedback loop than reading the trait twice — and it is the exact check to run after any upgrade, especially across the Laravel 12 → 13 boundary that 3.9.0 unlocks.

Pattern 4 — reuse across a monorepo of packages. The package's real design intent. If you maintain several internal Laravel packages, standardise their providers on the same handful of concerns so every package publishes config, migrations, and translations identically. The payoff is uniform vendor:publish behaviour and uniform --force semantics across your whole suite, which is hard to achieve by hand.

Pattern 5 — upgrade in place, verify the surface. 3.9.0 adds no traits, removes none, and changes no signatures: the diff is a Laravel 13 constraint bump plus README/banner/licence housekeeping. So the upgrade path is:

composer require dragon-code/laravel-support:^3.9 --with-all-dependencies
php artisan vendor:publish --provider="App\Providers\MyPackageServiceProvider" --list
php artisan vendor:publish --provider="App\Providers\MyPackageServiceProvider" --force

No code changes expected. The re-run matters because it is framework internals, not this package's code, that could shift the loader behaviour your provider depends on.

Integration tip: prefer mergeConfigFrom semantics (deep-merge of package defaults) over $this->app['config']->set(...). Whatever these traits do, mirror that behaviour in any provider you write by hand, so your packages stay consistent with the ones using the package.

Gotchas and Tips

Maintenance status has changed — re-verify, do not assume either way. Earlier releases went quiet enough that "archived, plan to vendor it" was the safe working assumption. 3.9.0 contradicts that: the author shipped Laravel 13 support himself (#49), merged a run of maintenance PRs (#45–#48), and the README update removed the "unstable" badge — a deliberate stability signal. Read that as maintenance restored, but recently and unproven. Concretely: pin a version, re-check the repo banner before you commit, and keep the vendoring escape hatch in your back pocket rather than treating it as mandatory.

Vendoring is now optional, not required. The old advice — copy the two or three traits you use into app/Support under the MIT licence — is still cheap and still worth it if you only touch one or two concerns. It is no longer the default recommendation, because upstream is shipping framework-compatibility work again and you would otherwise be maintaining that yourself every Laravel major.

Laravel 13 support is new code, not battle-tested code. 3.9.0 is the first cut that runs on Laravel 13, and this package has a tiny adoption base — five stars, near-zero dependents means the surface has been exercised mostly by the author's own packages. Budget debugging time proportional to how far you stray from default property values, and proportionally more on Laravel 13 than on 11/12, where the package has years of mileage. If you are still on 11 or 12, an older 3.x tag is the lower-risk choice and 3.9.0 buys you nothing.

No documentation layer. No docs site, no API reference. The 3.9.0 README work was images and badges, not prose — do not expect it to explain the traits now. You will be reading vendor/ source. Set up a fast path:

# jump straight into the trait you're about to use
grep -rn "trait HasConfig" vendor/dragon-code/laravel-support/src

Property/method name collisions. The provider concerns are designed to be used inside a ServiceProvider. If a trait declares boot() or register(), your own boot() will silently shadow it (or vice versa, depending on order) — PHP resolves trait methods against class methods with the class winning, and insteadof conflicts only trigger between two traits. If publishes silently do not happen, suspect exactly this. Debug by calling the trait method explicitly:

public function boot(): void
{
    $this->bootHasConfig(); // or whatever the trait names it
}

Lumen is a second-class citizen. No auto-discovery, and helpers that reach for config_path()/lang_path() behave differently under Lumen's directory layout. Test on Lumen explicitly if that is your target; do not assume Laravel-parity. Nothing in 3.9.0 touches Lumen. If you are on Lumen and cannot run Laravel 13, stay on your current pin — there is no reason to chase this release.

Check what it pulls in. Read the full composer.lock diff after install and after the 3.9.0 bump. A helpers package that drags a transitive dependency is a bad trade, and a version bump is exactly when constraints move.

Publishing tags collide across packages. If you use these traits in several packages, give each one a unique tag prefix, otherwise vendor:publish --tag=config from package A will also copy package B's config over it. Verify the tag naming inside each concern before shipping.

Extension point that actually matters: the traits are small and self-contained. The intended extension mechanism is inheritance — subclass your provider from a base provider that uses the concerns, then override the protected property or path method for the one package that deviates. There is no container binding or event to hook into, so do not go looking for one.

Debugging checklist when a publish does nothing:

1. php artisan vendor:publish --list — is your tag even registered?
2. Is the provider in bootstrap/providers.php / config/app.php (non-discovered setups)?
3. Did your own boot()/register() shadow the trait method?
4. Is the $package-style property set to the exact string the trait expects (including dashes vs underscores)?
5. composer dump-autoload after any namespace edits — trait loading is autoload-driven.
6. On Laravel 13 only: did the constraint actually resolve to 3.9.0, or is Composer still holding you on an older tag? composer show dragon-code/laravel-support settles it.

Bottom line for day-to-day use: reach for it when you are scaffolding an internal Laravel package and want the provider boilerplate gone. 3.9.0 removes the hard "abandoned" constraint, so this is a reasonable dependency again — but pin it, smoke-test vendor:publish on upgrade, and keep vendoring as a fallback rather than a plan. Do not add it to an application just for a couple of array/string helpers; the saved lines still do not justify the surface area.