Generator Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package. There is no day-to-day path to running it inside a Laravel app: it registers through AppKernel (or config/bundles.php on Symfony Flex), wires services through YAML/XML, and ships no service provider, no facade, and no extra.laravel block. composer require will download it and Artisan will never see it. Treat that as the headline finding, not a caveat.

The only realistic leverage for a Laravel developer is as read-only prior art for building or improving an internal make:* generator. Start there.

Step 1 — clone, never depend.

git clone https://github.com/LinkValue/MajoraGeneratorBundle.git /tmp/majora-generator

Do not add it to any composer.json. The repo is archived — the moment it is a dependency, you own 100% of its maintenance, with no upstream security triage and no PHP/Symfony compatibility work.

Step 2 — inventory the command surface and stubs.

The bundle mirrors SensioGeneratorBundle's commands:

• generate:bundle — scaffolds a Symfony bundle skeleton
• generate:doctrine:entity — derives an entity class from an interactive field spec
• generate:doctrine:crud — controller + templates + routing from an entity
• generate:doctrine:form — form type from an entity

Read those command classes and, more importantly, Resources/skeleton/. That directory is where the transferable value lives: field-spec parsing (name:string(32) issuedAt:datetime), namespace/naming derivation, and placeholder conventions in the stubs.

Step 3 — establish the gap before porting anything.

Laravel already ships a lot of this:

php artisan list make
php artisan stub:publish

make:model -mf, make:controller --resource, make:request, make:policy cover primitive class generation. The gap this bundle might inform is house conventions — audit columns, DDD folder layout, multi-file scaffolding — not the mechanics of emitting a class.

First use case — a half-day harvest spike. Read generate:doctrine:crud, note how it maps an entity to controller/route/template stubs, and write down which of those opinions you actually want to adopt. That write-up is the deliverable; an install is not.

Implementation Patterns

Harvest, don't adopt. The workflow is: read the upstream command, extract the convention, reimplement as an Artisan command in a first-party package. You never put majora/generator-bundle in the dependency tree — you crib the shape.

Port the field-spec parser, not the wiring. The interesting bit in generate:doctrine:entity is turning --fields="number:string(32) issuedAt:datetime" into typed properties and validation. That logic is framework-agnostic and maps cleanly onto an Artisan signature:

protected $signature = 'make:entity
    {name : Entity name}
    {--fields= : Comma-separated field specs, e.g. name:string(32) issuedAt:datetime}';

Inside, parse the string into an array of {name, type, length, nullable}, then feed those into your own Blade-style stub replacements. The Symfony version does the same thing with Twig; the template engine is the only real difference.

Mirror the skeleton layout. Copy the structure of Resources/skeleton/ into a publishable stubs/ directory in your internal package, then lean on Laravel's own mechanism:

php artisan vendor:publish --tag=mygenerator-stubs

This is the pattern make:* already uses, and matching it keeps your tool familiar. Publishing stubs is important — it lets teams override naming, audit fields, and folder layout without forking your package.

Scripted / non-interactive replay. The upstream generators are prompt-driven. Study the question order once, then build your Artisan version so every option is flag-settable and --no-interaction works end-to-end. This is what makes generators usable in CI and in scaffolding scripts; the Symfony version only half-supports it, which is one of its real weaknesses.

Compare against make:model before you build. For most "I want an entity" cases, php artisan make:model Invoice -mf plus a published model stub covers it. Reserve a custom generator for the cases Artisan genuinely can't express: DDD folder layouts, multi-class scaffolding (entity + repository + policy + factory + test in one command), or enforcing mandatory audit columns.

Gotchas and Tips

The category error is the whole thing. It will autoload-install in a Laravel app and do nothing. Someone will spend an hour diagnosing "why doesn't the bundle register" before realizing Symfony bundles aren't Laravel packages. If you write anything about this internally, put that sentence first.

Archived means no upgrade path. No Symfony 6/7 work, no PHP 8.2+ fixes, no security response. With 2 stars and 0 dependents there is no community to catch bugs — you would be the only maintainer. The MIT license lets you fork, but permission to fork ≠ reason to depend; the fork needs a named owner and a maintenance budget, not just a composer require.

Do not pin a separate symfony/console version. Artisan already depends on Symfony Console transitively, version-managed by Laravel. Adding a second constraint to accommodate anything from this bundle will break Laravel's console in ways that are painful to unwind. Keep the Console version where Laravel put it.

Stub drift is the silent failure mode. If you port stubs and don't revisit them, generators will keep emitting code that no longer matches current idioms — new engineers copy the stale patterns and propagate them. Reconcile stubs on every Laravel major upgrade; make that a line item in the upgrade runbook, not a "someday."

Interactive prompts break in CI. The upstream generators assume a TTY. If any of their prompt sequences get copied into your Artisan commands, make sure you support full flag-driven execution so --no-interaction actually completes — otherwise the command is useless in scripts and containers.

Registration is AppKernel, not bundles.php. If you're looking at the upstream README, the $bundles[] = new Majora\Bundle\GeneratorBundle\MajoraGeneratorBundle(); snippet is Symfony 2/3 era. On Flex/Kernel apps it's config/bundles.php. Neither applies to Laravel — the point is just to recognize the vintage and don't chase a fix that doesn't exist.

Keep it in dev only, if you ever touch it in a Symfony context. The upstream design assumes dev/test environments. That constraint is worth honoring if a legacy Symfony service legitimately wants it — the generator should never autoload in production.

Extension points are worth one look. The bundle's generator architecture (abstract generator + per-artifact subclass) is a reasonable template if you want your Artisan commands to share plumbing. But for a first internal generator, one command with an inline stub registry is faster and easier to maintain. Don't over-engineer the harvest.