Laravel Make Extender Laravel Package

Getting Started

• Install as a dev dependency — these are scaffolding tools, not runtime code:

  composer require --dev limewell/laravel-make-extender
  

  Laravel package discovery registers the service provider automatically; confirm the new commands appear with php artisan list | grep make:.
• First place to look is the README's command table and the package's stubs/ directory — the stubs are the actual contract for what each generator produces, and they're what you'll customize first.
• First real use case: php artisan make:helper to drop a function file into app/Helpers and have it autoloaded without manually editing composer.json. This is the package's highest-value feature — the other generators mostly save a copy/paste.
• If the package exposes publishable stubs/config, publish them early (php artisan vendor:publish --provider="Limewell\...ServiceProvider" or the tagged variant shown in the README) so your team's conventions live in-repo rather than in vendor/.

Implementation Patterns

Helpers. Generate one file per concern (StringHelper, ArrayHelper) rather than a single god-helper. Because the package handles autoloading, the workflow is "generate → write functions → call them anywhere." Keep them pure and stateless so they stay testable without bootstrapping Laravel.

Service classes. Use make:service for orchestration that doesn't belong in a controller or model — third-party API wrappers, multi-step domain operations. Then bind them in a service provider and inject via constructor. Treat the generated class as a blank canvas; the package gives you the file, you give it the contract (an interface + binding) so it's mockable in tests.

Builder scopes. Generate the scope, implement Scope, then apply locally (->scoped(FooScope::class) per query) or globally in the model's booted() method. This is the correct home for reusable query fragments that would otherwise become model bloat or magic string scopes.

Traits. Use for cross-model concerns (slugging, soft-delete-adjacent behavior, activity logging). Generate into a sensible namespace (App\Models\Concerns) and keep them free of hard-coded model assumptions.

Custom casts. One cast per file, implementing CastsAttributes. Best used for value objects (Money, Email, Coordinates) so the rest of the app never sees raw strings.

Collection macros. Register in a dedicated service provider's boot(), guarded appropriately so they aren't redefined on repeated boots (notably in long-running workers or parallel tests). Keep macro bodies small — they're hard to discover via IDE.

View composers. Generate the composer, then register it in a service provider via View::composer('dashboard.*', DashboardComposer::class). Prefer class-based composers over closures so they're testable.

Stub customization as a workflow pattern. Publish stubs, add your project's namespace, license header, strict types, and declare(strict_types=1). Every developer on the team then generates consistent files regardless of who runs the command.

Gotchas and Tips

• Autoload friction. Helper autoloading usually depends on either composer.json files entries or a provider that requires the directory. After generating your first helper, if the function is undefined, run composer dump-autoload and re-check. Never assume generating = immediately callable everywhere.
• Command name collisions. Laravel ships make:cast, make:scope, make:observer, etc. If your Laravel version already has a command the package also registers, behavior depends on registration order — verify which one wins with php artisan list before relying on the package's output shape.
• Stubs get overwritten on upgrade. Published stubs are a fork; when the package releases a new version, diff its stubs against yours. The 2025-08 release could change file signatures.
• It's a scaffolding tool, not a runtime dependency. Keep it in require-dev. Nothing in production should reference the package namespace.
• Small package, low adoption (~36 stars). Pin the version in composer.json, and smoke-test generators after any Laravel upgrade — minor Laravel internals changes can silently break make command signatures before the package catches up.
• Test hygiene. Collection macros and global scopes leak across tests if registered in the wrong lifecycle hook. Register macros in a provider's boot(), not in register(), and reset global scopes in tearDown() when using them.
• Debugging generators. If a command fails, run with -vvv. Most failures are stub-not-found or namespace resolution issues — check that the stubs directory is published/wired correctly.
• Extension points. The main one is stubs; otherwise this package is deliberately shallow. If you need generator behavior it doesn't offer (e.g., generating a service and its interface), wrap it in a small custom Artisan command rather than forking the package.