Generator Bundle2 Laravel Package

Getting Started

This is a low-traffic, single-maintainer Symfony generator bundle (a fork/rewrite in the vein of SensioGeneratorBundle). Treat it as scaffolding tooling you run once per feature, not a runtime dependency.

1. Install and register.

   composer require --dev wame/generator-bundle2
   

   Register it only in dev/test. On Symfony 3 and earlier that means AppKernel::$bundles[]; on Symfony 4+ add it to config/bundles.php guarded by env('dev'). Because it is dev-only tooling, keeping it out of production autoloading avoids surprises.

2. Find out what it actually ships. Before writing any code, run:

   php bin/console list generate
   php bin/console help generate:<command>
   

   The command namespace and available generators are the real API surface here — there is essentially no documentation ecosystem around this package, so list/help plus the bundle's Command/ directory and Resources/skeleton/ templates are your source of truth.

3. First use case: scaffold one CRUD slice from an existing Doctrine entity. Create the entity (by hand or with an existing maker), then generate the form/controller/routing/templates for it. Inspect the generated diff in git before committing — that is the fastest way to learn the bundle's conventions (naming, namespaces, service wiring).

4. Verify compatibility early. With ~1 star and zero dependents, assume the package targets an older Symfony (2.x/3.x era conventions: AppKernel, @Template annotations, getBlockPrefix()). Confirm the Symfony version constraint in its composer.json against your app before investing time. If you are on Symfony 5+/6+, prefer the official MakerBundle and use this only if you have a specific reason.

Implementation Patterns

Scaffold-then-edit, not regenerate. The productive loop is: generate once into a clean working tree, review the diff, then own the code. Keep generation in its own commit so the "generated vs. hand-written" boundary stays obvious in review and in git blame.

Generate from an existing entity, not from scratch. The generator's value is wiring (form type, controller actions, routes, Twig templates) around a Doctrine entity you already modeled. Model the entity first with explicit column types and associations; the generator infers form fields and CRUD actions from the mapping, so a well-annotated entity yields much better output than a bare one.

Interactive vs. flagged runs. Use the interactive prompts the first time to discover the options (bundle namespace, entity, route prefix, template format). Once you know the answers, replay the command non-interactively in a Makefile target or shell script so scaffolding a new module is one command and reproducible across the team.

Namespace into your app, not the vendor bundle. Generate into your own bundle/namespace (e.g. App\Admin\...) so generated code lives with the code it serves. This also keeps template overrides and route prefixes colocated with the feature.

Override templates rather than patching the bundle. If the skeleton output doesn't match house style (base template, block names, Bootstrap/Tailwind markup), copy the relevant file from Resources/skeleton/ into your app's template override path and adjust. Never edit files under vendor/ — a composer update erases them.

Pair with a formatter/linter in the same step. Generated PHP often needs a pass through PHP-CS-Fixer and generated Twig through your linter. Wire both into the same Make target so scaffolded code lands already conforming, which keeps the "generated vs. edited" diff clean.

Gotchas and Tips

• Maintenance risk is the headline gotcha. One star, zero dependents, MIT, single maintainer. Pin the version in composer.json, commit composer.lock, and be prepared to fork. Audit the Command/ classes before trusting them with anything destructive — some generators will prompt to overwrite existing files, others won't.
• Overwrite prompts are not a backup. Always scaffold on a clean git tree. If a generator silently replaces a controller or template, git diff is your only recovery path.
• Namespace/command collisions. If SensioGeneratorBundle or MakerBundle is also installed, command names or generated class names can clash. Check bin/console list for duplicates and disable one of them in dev.
• Doctrine mapping assumptions. Generated forms and CRUD assume the entity is managed and that associations are set up as the generator expects (owning side, nullable, cascade). Wrong assumptions surface as runtime form/relationship errors, not generation errors.
• Template resolution order. Overrides resolve by bundle name and path; if your override isn't picked up, run with -vvv and confirm the bundle's template path and your app's override path actually match. A wrong bundle alias silently falls back to the vendor default.
• Debug with verbosity. php bin/console generate:<cmd> -vvv exposes the exact skeleton files copied and target paths written — the quickest way to understand what a generator did when the output looks wrong.
• Extension points are thin. Realistically your customization levers are: template overrides, generating into your own namespace, and post-generation formatting. Don't expect a service-container-driven, configurable generator architecture; check DependencyInjection/ for what config (if any) is actually exposed.
• Don't ship it to production. Keep it in require-dev and out of production bundle registration; it adds autoload weight and attack surface for zero runtime benefit.