Laravel Extras Laravel Package

Getting Started

teners/laravel-extras is a grab-bag utility package: extra Artisan commands, reusable traits, and helper classes. There is no hosted documentation beyond the README, so treat the source in vendor/teners/laravel-extras/ as the canonical reference.

Install and confirm discovery

composer require teners/laravel-extras
php artisan package:discover

It ships a service provider with Laravel auto-discovery, so no manual registration is normally needed. Confirm it loaded:

php artisan list | grep -i teners

Where to look first

1. vendor/teners/laravel-extras/composer.json — check the autoload.files entry. If the package registers a global helpers file, that is the fastest way to see what functions appear in your app namespace.
2. vendor/teners/laravel-extras/src/Commands/ — the command class names and $signature strings tell you exactly what is available.
3. vendor/teners/laravel-extras/src/Traits/ — the traits are the highest-value surface; read the property/method names before adopting them.

First use case

The lowest-risk entry point is a single Artisan command. Pick one that replaces a script you already run by hand (a make/scaffold command or a cleanup command), run it in a throwaway branch, and inspect the diff it produces. Adopting a trait on an Eloquent model is the second step, and only after you have read that trait's boot* methods.

Implementation Patterns

Add commands to existing workflows, not new ones. If the package provides scaffolding commands, alias them in your composer.json scripts so they run alongside pint and test, rather than asking the team to memorize a new verb:

"scripts": {
  "scaffold": ["@php artisan vendor:publish --tag=extras", "@php artisan extras:make"]
}

Wrap trait usage behind your own base class. Rather than sprinkling use SomeExtrasTrait; across dozens of models, apply it once to an App\Models\BaseModel (or a shared abstract). This gives you a single place to swap or drop the dependency later, which matters at 0 dependents and 5 stars — the package could go unmaintained.

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Teners\LaravelExtras\Traits\SomeTrait; // verify exact FQCN in src/Traits

abstract class BaseModel extends Model
{
    use SomeTrait;
}

Prefer the classes over the global helpers. If the package autoloads a helpers file, those functions live in the global namespace and cannot be namespaced or mocked. Call the underlying class statically inside your own thin helper so you keep a seam for testing and future replacement.

Pin the version and lock it in CI. With a recent release date and a small maintainer surface, use a caret constraint against a known-good tag and let composer.lock do the rest. Add a smoke test that boots the app and runs php artisan list so a broken service provider fails CI rather than production deploy.

Test the traits in isolation. Because these are framework-coupled traits, use orchestra/testbench-style model tests for anything you lean on:

it('formats the attribute', function () {
    $model = new class extends \App\Models\BaseModel {};
    expect($model->someAccessor())->toBe('...');
});

Gotchas and Tips

• No docs means no contract. Method names, config keys, and command signatures can change between patch releases. Diff vendor/teners/laravel-extras after every composer update if you depend on more than one or two pieces.
• Global helper collisions. An autoloaded files entry can redeclare a function name Laravel, Symfony, or another package already defines, producing a fatal Cannot redeclare error. If boot fails after install, comment out the files autoload in your own root composer.json override or drop the package.
• Trait boot methods fire automatically. Laravel calls boot{TraitName} on model traits. Two traits both touching creating/saving/casts can silently conflict — check for a boot* method before stacking them on the same model.
• Command name collisions. A $signature clashing with an existing Artisan command makes the later registration win, which is order-dependent and confusing. Run php artisan list and grep before assuming your command is the package's.
• Config publishing. If a config file exists but is undocumented, php artisan vendor:publish --provider="Teners\LaravelExtras\LaravelExtrasServiceProvider" (verify the provider name in composer.json extra.laravel.providers) will surface it. Published config is merged, not replaced — stale values survive upgrades, so re-publish into a scratch directory to see new keys.
• Caches mask provider changes. After install or update, run php artisan optimize:clear; a cached bootstrap/cache/services.php will hide a newly discovered provider and make the package look broken.
• Extension points are the classes themselves. There is no plugin architecture here — the practical extension point is subclassing a command or composing a trait into your own class rather than editing vendor files. Never patch vendor/; fork to a VCS repository in composer.json if you need a fix upstreamed.
• Budget for an exit. With zero dependents, there is no crowd to surface breaking changes. Keep any trait usage to a handful of lines so that removing the package later is a delete-and-inline operation, not a refactor.