Laravel Somake Laravel Package

Getting Started

soyhuce/laravel-somake extends Laravel's make:* family with generators for the layers most Laravel codebases end up hand-rolling (services, repositories, actions, and similar collaborators). The 3.1.0 release is a maintenance/compatibility release — its headline is that the test suite now runs against Laravel 12 — so day-to-day usage is unchanged from 3.0.x.

1. Install:

   composer require soyhuce/laravel-somake
   

   Confirm the resolved version is ^3.1 before you start. 3.1.0 contains no source-level API changes, so teams already on 3.0.2 can bump with a plain composer update soyhuce/laravel-somake.

2. Discover what it actually gives you before reading docs — the authoritative list is the artisan registry:

   php artisan list | grep make
   

3. Publish the configuration and stubs, because the defaults encode Soyhuce's namespace conventions, not yours:

   php artisan vendor:publish --tag=somake-config
   php artisan vendor:publish --tag=somake-stubs
   

   Check config/somake.php for the namespace/path mapping per generated type.

4. First real use case: generate a service for a piece of logic you'd otherwise stuff into a controller, verify the namespace resolves, then wire it into the container. Do this once before you onboard the team — a misconfigured namespace is the single most common reason people bounce off scaffolding packages.

Where to look first, in order: config/somake.php → the published stubs → the generated file in your IDE. Don't start from the README's examples; start from what your config produces, since that's what your team will actually type.

Implementation Patterns

Namespace mapping as team contract. The config file is the package's real API. Agree on App\Services, App\Repositories, App\Actions (or whatever your architecture calls them) in one PR, commit config/somake.php, and treat it as reviewable code rather than local preference. Everything downstream — generated namespaces, use statements, test paths — follows from it.

Custom stubs over post-generation editing. If your generated services should implement an interface, take constructor dependencies, or carry a @throws docblock, edit the published stub once. Regenerating with --force then reproduces your convention instead of Laravel's default. This is the highest-leverage thing you can do with the package: ten minutes on stubs saves hours of "everyone's services look different."

Layer-by-layer adoption. Don't generate all four layers on day one for a codebase that has none. Pick the layer you already hand-write most (usually services), generate those for a sprint, and only add repositories/actions once the first layer's shape has stabilised. Scaffolding packages amplify whatever convention you feed them, including a bad one.

Pair with Laravel's own generators. make:model, make:controller, and make:request remain the right tools for framework primitives. Use somake for the non-framework collaborators and let the two families coexist — e.g. make:model then a somake repository that type-hints it.

Migration/CI note for this release. Add Laravel 12 to your test matrix only after you've confirmed the rest of your dependency graph supports it. 3.1.0's own CI proves the package works on Laravel 12, but that says nothing about your other packages, and a green somake suite with a red app suite is a confusing place to be.

Keep generators out of production paths. Generated classes are source, so they belong in version control and code review like anything else. Don't wire generation into deploy scripts.

Gotchas and Tips

Published stubs are frozen at publish time. This is the big one. Upgrading 3.0.2 → 3.1.0 will not refresh files in resources/ or stubs/. After any version bump, diff your published stubs against the package's originals before assuming you've picked up template changes:

diff -ru vendor/soyhuce/laravel-somake/stubs stubs

If the vendor path differs, find it with composer show soyhuce/laravel-somake.

This release is low-risk but verify the constraint. 3.1.0 changes only CI (dependabot/fetch-metadata 2.2.0 → 2.3.0) and test coverage (Laravel 12). There are no deprecations, no breaking changes, and no new features. If you're on Laravel 12 and were holding at 3.0.2 out of caution, the blocker is now cleared — but read composer.json's illuminate/* constraint to confirm it's permissive rather than assuming the test run implies it.

Config caching will bite you. If you use php artisan config:cache in any environment, changes to config/somake.php are invisible until you re-cache. Symptom: "I fixed the namespace and it still generates the old one." Run php artisan config:clear first, always.

New namespaces need PSR-4 registration. Generating into App\Services when composer.json only autoloads App\ under a different root, or when you've introduced a new top-level namespace, produces classes that exist on disk but fail to autoload. composer dump-autoload after changing namespace config.

Command-name collisions. Any package (or your own App\Console\Commands) registering make:service shadows or is shadowed by somake's. If a command behaves unlike the docs, run php artisan make:service --help and check the class shown — it may not be somake's.

--force overwrites without backup. Useful while iterating on stubs against a throwaway class, dangerous against a real one. Pair with a clean git status and nothing else.

Extension points are the stubs and the config, not subclassing. The package is deliberately thin. If you need behaviour the stubs can't express — conditional constructor injection, generating a paired test, registering the class in a service provider — write a small project-local generator command that calls the somake one or renders the stub itself. Fight the urge to vendor-patch; a fork of a maintenance-only package is a fork you'll maintain forever.

Debugging checklist when a generation looks wrong: is the config cached → is the stub the one you think (check the published copy, not the vendor copy) → does the target namespace autoload → is this command actually somake's. That order resolves nearly every report.