Crud Generator Laravel Package

Getting Started

First, the reality check. mwsimple/crud-generator is a Symfony bundle (CrudGeneratorBundle), not a Laravel package. It ships no ServiceProvider, no config/crud-generator.php, no Artisan commands, and depends on Doctrine ORM + Twig + the Symfony 2/3 kernel. If you are on Laravel, composer require mwsimple/crud-generator will install but do nothing for you. Leverage it in one of two ways:

1. Inside a legacy Symfony 2/3 app you inherited and still maintain.
2. As a template reference — read its skeletons and port the scaffolding pattern to your own Artisan generator.

Minimal steps for case 1:

composer require mwsimple/crud-generator

// app/AppKernel.php
new MWSimple\Bundle\CrudGeneratorBundle\MWSimpleCrudGeneratorBundle(),

Then, in order:

1. Confirm the command namespace first — it is not documented consistently across versions. Run php app/console list and grep for crud. Do this before anything else; guessing the command name wastes more time than any other step with a 2016-era bundle.
2. Have a mapped Doctrine entity ready. The generator reads @ORM\Column metadata to infer field types, form widgets, and validation. An unmapped or annotation-free entity produces empty scaffolding.
3. Generate for one small entity (a lookup table like Category), not your 40-column Order table.
4. Inspect the four artifacts: Controller, FormType, Twig views (index/new/edit/show), and the route snippet.

First use case: point it at a simple entity in a legacy admin backend and let it emit the boilerplate controller + form + index/edit templates. You are buying back maybe an hour per entity — that is the entire value proposition, so measure it that way.

If you are greenfield on Laravel, skip the install and read Resources/skeleton/ in the repo instead. Then map it to:

php artisan make:model Category -mcr
php artisan make:request StoreCategoryRequest
php artisan make:controller CategoryController --resource --model=Category

Implementation Patterns

Entity-first, generate-once, then hand-edit. The generator is a one-shot scaffold, not a live code generator. The sustainable workflow is:

git checkout -b scaffold/category
php app/console <crud-command> --entity=AppBundle:Category
git diff   # review every generated line before committing

Treat the output as a code review artifact, not a build step. Never re-run the generator over a file you have already customized — commit first so you can git checkout -- whatever it clobbers.

Override the skeletons rather than patching generated files. Symfony's bundle resource override convention is the extension point here: place files at app/Resources/MWSimpleCrudGeneratorBundle/... (or copy the skeleton directory into your own generator) so every future generation matches house style — your base controller, your layout block names, your naming conventions. Doing this once pays for itself on the second entity.

Compose with a base admin controller. Generated controllers typically extend the framework controller directly. Change the skeleton so they extend your AdminController instead, inheriting auth checks, flash-message helpers, and pagination defaults. This is the single highest-leverage edit you can make to the templates.

Keep generated routes in one imported file. Have the generator emit a resource block, then import it centrally:

# app/config/routing.yml
admin_category:
    resource: "@AppBundle/Resources/config/routing/category.yml"
    prefix:   /admin

Then wrap the prefix in your firewall. Generated controllers almost never include authorization — assume you must add it.

Layer validation separately. The generated FormType gives you widgets and basic required flags from Doctrine nullable/长度 metadata. Real constraints (unique slugs, min/max, Assert\Email) belong in the entity or a dedicated validator, not hand-added to a file the generator owns.

For Laravel developers porting the pattern: the structural mapping is direct — FormType → FormRequest, Twig index.html.twig → Blade index.blade.php, generated Controller actions → resource controller methods, route YAML → Route::resource(). What you should not port is the field-type inference; Laravel migrations plus $casts and a Blueprint-style schema reader give you the same information more reliably.

Integration tip: generate into a dedicated namespace (AppBundle\Admin\) rather than the default, so scaffolded code is trivially identifiable later — and trivially deletable when you replace it.

Gotchas and Tips

• Abandoned since October 2016. Expect PHP 7.2+ and Symfony 4/5 Flex incompatibilities: no autowiring, no AbstractController, service definitions in XML/YAML from the Symfony 2 era. Budget for a vendored fork if you must run it on a modern runtime.
• 15 stars, 0 dependents. There is effectively no community. When it breaks, the source is the documentation. Read the command class and the skeleton directory before searching anywhere else.
• It is not a Laravel package. No php artisan vendor:publish, no config file, no facade. If your assessment assumed Laravel ergonomics, discount the whole thing and evaluate only the templates.
• Overwrite semantics. Most generators of this vintage write files unconditionally. Always run on a clean working tree, and never on a branch with uncommitted work.
• Doctrine metadata assumptions. Naming strategy mismatches (camelCase properties vs snake_case columns) mangle labels and form field names. Relations (ManyToOne, ManyToMany) are often scaffolded as raw IDs or skipped entirely — plan to hand-write association widgets.
• No pagination, filtering, or sorting out of the box. Generated index actions typically findAll(). On any real table this is a production incident waiting for a support ticket — add a paginator and a search form before shipping.
• Debugging checklist when generation silently produces nothing: (1) bundle registered in the kernel, (2) app/console cache:clear, (3) entity actually has Doctrine mapping loaded (doctrine:mapping:info), (4) entity bundle notation correct (AppBundle:Category, not a FQCN), (5) run with -v to see which skeleton paths were resolved.
• Template resolution is the usual failure point. Generated output that looks "default" almost always means your override path is wrong and the bundle's own skeleton won. Verify by temporarily editing the bundle skeleton and confirming the change appears.
• Extension points, in order of safety: (1) override templates under app/Resources/, (2) subclass the generator command in your own bundle, (3) fork the repo. Never edit vendor/ in place.
• Security is entirely your job. Generated controllers ship unauthenticated. Add the role check in the skeleton's __construct or a kernel.controller listener before the first deploy.
• Verdict for a Laravel team: this is a research artifact. Spend thirty minutes reading its skeletons for scaffolding ideas, then use blueprints, laravel-generator, or plain make:* commands. The 2016 release date, zero dependents, and Symfony coupling make adoption a net cost.