Generators Laravel Package

Getting Started

Install as a dev dependency so the generators are available in local/CI environments but not shipped to production:

composer require --dev bpocallaghan/generators

The service provider is auto-discovered on Laravel 5.5+. Confirm it registered by running php artisan list and looking for the package's make:* commands — if they're missing, check bootstrap/providers.php (Laravel 11+) or config/app.php for the provider entry, then composer dump-autoload.

Next, publish the config and the stubs. Run php artisan vendor:publish without arguments first to see the available tags/groups, then publish the Generators provider group:

php artisan vendor:publish --provider="Bpocallaghan\Generators\GeneratorsServiceProvider"

You should end up with config/generators.php (namespaces, paths, stub overrides) and a stubs/ directory at the project root or under resources/. Commit both — the point of this package is that stubs become part of your project's conventions, not something regenerated per machine.

The first real use case: replace your team's muscle-memory make: calls with the package's versions so every generated file starts from your stub. For example, generating a controller that already imports your base controller, uses your traits, and carries the team's PHPDoc header:

php artisan make:controller Admin/UserController

Open the generated file and diff it mentally against what php artisan make:controller would have produced. That diff is the value proposition — if it's empty, your stubs aren't wired up yet.

Implementation Patterns

Stub-first customization. Keep published stubs in version control and treat them as the source of truth for boilerplate. Any time you find yourself editing a freshly generated file the same way twice, move that edit into the stub. This is the highest-leverage workflow the package enables.

Layer the config over the stubs. config/generators.php controls things like namespace prefixes and output paths; the stubs control file contents. Use the config to point generation at a modular structure (e.g. app/Modules/Billing) without duplicating stub files per module, and use stubs only when content actually differs.

Scaffold a feature in one pass. A typical integration flow for a new domain object:

php artisan make:model Invoice -m      # model + migration
php artisan make:request StoreInvoice # form request
php artisan make:controller InvoiceController
php artisan make:policy InvoicePolicy

Because every command reads the same stubs, all four files arrive already namespaced, already importing your base classes, and already matching your code style — no post-generation cleanup pass.

Team onboarding. New developers run the same vendor:publish + commit workflow, so generated code never drifts by editor or by Laravel version. Document the publish command in your README next to your other composer setup steps.

CI guardrail. If you want to enforce stub consistency, add a small test that generates a sample file into a temp path and asserts it contains required markers (your header block, base class import, etc.). This catches stub breakage before it silently propagates through a sprint of scaffolding.

Extending with your own stubs. Add new stub files alongside the published ones and reference them from config where supported. For anything the package doesn't ship, fall back to a small custom Artisan command that wraps stub:replace-style logic — don't fight the package's command set.

Gotchas and Tips

• Some commands shadow Laravel's built-ins. If the package registers a make:controller, make:model, etc., it will win over the framework version, and the output will differ from what the Laravel docs show. That's the whole point — but it means Stack Overflow answers about make:controller behavior may not match your project. Call this out in onboarding docs.
• Broken stubs fail at generation time, not install time. If you mangle a placeholder token while editing a stub, the command runs and produces a file with literal placeholder text instead of substituted values. After editing any stub, always generate one file and read it end-to-end before committing the stub change.
• Config cache. php artisan config:cache will freeze config/generators.php. If path/namespace changes don't seem to take effect, run php artisan config:clear — this is the single most common "the package is broken" false alarm.
• --force overwrites silently. The package exposes a force flag on its generators; use it deliberately and never in a script that runs against a working tree you haven't committed.
• Case sensitivity across OSes. Path settings in config and namespace segments in config are used to build file paths. macOS's case-insensitive filesystem hides mistakes that fail on Linux CI. Prefer exact-cased namespaces consistent with PSR-4.
• Version pinning matters. The last release was April 2024, so verify the composer.json constraint against your Laravel version before upgrading the framework. Pin the package with a ^ constraint that matches the Laravel major you're actually on, and bump both together.
• Dev-only by design. Since it's a require-dev package, generation commands won't exist on production hosts. Don't reference them in deploy scripts or composer install --no-dev build steps.
• Namespace collisions when you have your own generators. If you later add a custom make: command, name it differently from both Laravel's and this package's commands. Command name collisions produce confusing "which one ran?" behavior during scaffolding.