Weave Code
Maker Bundle Laravel Package
symfony/maker-bundle
The Symfony MakerBundle is the fastest way to generate common Symfony code like commands, controllers, form classes, and event subscribers. It produces working skeletons that follow current best practices and target the latest Symfony LTS.
Symfony MakerBundle is the fastest way to generate the most common code a Symfony app needs — commands, controllers, form classes, event subscribers, and more. Each maker produces a working skeleton that follows current recommended best practices, with sensible defaults and minimal configuration.
It targets developers new to a Symfony feature who want a starting point without writing boilerplate — from absolute beginners to experienced developers picking up an unfamiliar component.
- Zero-config scaffolding for the most common Symfony classes
- Generated code follows current recommended defaults
- Makers for commands, controllers, forms, subscribers, and more
- Built for Symfony's latest LTS
Frequently asked questions about Maker Bundle
- Can I use symfony/maker-bundle in a Laravel application?
- It is a Symfony bundle built around Symfony's dependency injection container, Doctrine and Twig, so there is no native Laravel integration. You can install it with Composer, but the makers generate Symfony-style code such as services, attributes and Doctrine entities rather than Eloquent models or Blade views. For most Laravel projects, Laravel's own make commands or laravel-shift/blueprint are a better fit. Treat MakerBundle as useful only if you are deliberately running Symfony-style code inside a Laravel app.
- Does symfony/maker-bundle 1.68 work with Laravel 10?
- Unlikely without significant changes. Version 1.68 raises the floor to Symfony 7.4+ and PHP 8.2+, while Laravel 10 sits on Symfony 6.4-era components and still supports PHP 8.1. Composer will usually fail to resolve Laravel's symfony/* constraints against ^7.4. Laravel 11 and 12, with a PHP 8.2+ baseline and Symfony 7.x components, are closer, but the constraints still have to line up.
- How do I install symfony/maker-bundle?
- Install it as a dev dependency with composer require --dev symfony/maker-bundle. In a Symfony app, Flex enables it automatically and you run makers with php bin/console make:... commands. Laravel has no bundle registration or Symfony kernel by default, so you would need to wire the commands into a console application yourself before they can run.
- What can I generate with Symfony MakerBundle?
- The common makers cover commands, controllers, form classes, event subscribers, entities and CRUD, plus decorators, Twig extensions, messages, schedules, webhooks and security. Each maker produces a working skeleton that follows Symfony's current recommended defaults with minimal configuration. The output targets Symfony conventions, so generated services, attributes and Doctrine mappings do not map one-to-one onto Laravel patterns.
- Is MakerBundle a replacement for Laravel's make commands or Blueprint?
- No. Laravel's artisan make:* commands and laravel-shift/blueprint are built for Eloquent, Blade, migrations and Laravel's container, which is exactly where MakerBundle is weakest. MakerBundle is purpose-built for Symfony's DI, Twig and Doctrine stack, and its maintainers explicitly keep the scope Symfony-focused. Using both in one project tends to create redundant, conflicting scaffolding.
- Does MakerBundle support non-interactive or CI-driven code generation?
- Yes, and version 1.68 improves this significantly. The release fixes --no-interaction crashes across the CRUD, controller, security, schedule, twig-extension, webhook and message makers, and adds --field and --relation flags so entity generation can be scripted. That removes the biggest prior blocker for CI use. Remember the BC promise: command arguments and options may change between minor releases, so pin versions in automation.
- Can I customize MakerBundle templates to generate Laravel-style code?
- Only with effort, and it goes against the project's stated direction. The 1.68 scope notes say broad extensibility, configurability and pluggable generators are out of scope, and recommend coding agents or other code-generation tools for custom templates and opinionated code shapes. You can override templates and wrap makers, but 1.68 changed output shapes with invokable commands, attribute-based Twig extensions, decorators and final entities, which will invalidate overrides built on 1.67.x. For Laravel conventions, Blueprint or dedicated AI skills are a lower-maintenance route.
- What changed in symfony/maker-bundle 1.68.0?
- It adds a make:decorator maker, makes make:command invokable by default with prompted arguments and options, adds attribute-based Twig extensions, and introduces --field and --relation flags plus PHP 8.4 property-hook support for make:entity. It also raises requirements to Symfony 7.4+ and PHP 8.2+, removes PHP CS Fixer integration, and applies the generate_final_entities config to generated entities. These behavioural changes are not opt-in, so review generated diffs after upgrading.
- Is MakerBundle still maintained, and what is its backwards compatibility policy?
- Yes, it is an actively released Symfony project, but it follows Symfony's BC promise with two important caveats: command arguments and options may change between minor releases, and generated code may change between minor releases. Only the latest Symfony LTS is supported, and the generated code targets that LTS. For Laravel teams this means you are tracking Symfony's release cadence, now 7.4+, rather than Laravel's, which is a real maintenance consideration.
- What are the alternatives to symfony/maker-bundle for Laravel developers?
- For Laravel, use artisan make:* for everyday scaffolding and laravel-shift/blueprint for schema-driven generation of models, migrations, controllers and tests. If you want AI-assisted generation that follows project conventions, the MakerBundle docs now point to Symfony Mate, and coding agents with dedicated skills are the recommended path for custom templates. MakerBundle itself remains the right choice only when the target application is genuinely Symfony-based.
Weaver
How can I help you explore Laravel packages today?