Redefine the scope of MakerBundle

[GromNaN]

Following a discussion among Symfony core team members about the future of MakerBundle and its relationship with Symfony Mate (part of symfony/ai), this PR documents a clearer, narrower scope for the project.

Context

Key points that emerged from the discussion:

• MakerBundle has become exceptionally hard to maintain. The test suite is slow and complex to debug (each test spins up a temporary project and runs commands).
• Every new option adds combinatorial complexity, both for users and for maintainers, sometimes turning generators into meta-programming through the CLI.
• Most of the templates are simple boilerplate that require no AI at all. The complexity lives in advanced generators (notably make:entity).
• MakerBundle still has real value for newcomers, for training sessions, and for offline / AI-free workflows. Dropping it entirely is not on the table right now.
• Coding agents with dedicated skills (e.g. Symfony Mate, Laravel Boost style) are a better fit for customization, edge cases, and opinionated variations.

Proposal

Rather than dropping MakerBundle, we narrow its scope:

• Target audience: newcomers starting a Symfony project without writing boilerplate.
• Generate code that reflects our current recommended best practices, with sensible defaults and minimal configuration.
• Reject options and switches that exist only to cover edge cases or personal preferences.
• Redirect requests for extensibility, custom templates, alternative target directories, or opinionated code shapes to coding agents and skills-based tools.

Examples of requests that fall outside this new scope:

• Extending the makers (Unable to extend existing makers because they are declared final #1787)
• make:entity non-nullable option (make:entity to generate non-nullable fields #1679)
• Configurable template paths (configurable template paths #1135)
• Changing target directories (Support target directories other than the first one matching a namespace #1399)

Example of requests that could be accepted, changing the generated code:

• Invokable command generation ([make:command] Create invokable command by default #1746)
• $form->createView() in controllers (Update Controller.tpl.php to use createView() method by default #1709)
• specify the table name of an entity ([make:entity] Allow specify the table name #1730)

The README already warns that generated code can change in any version; this PR makes the underlying philosophy explicit.

[kbond]

Within this new scope, if we have make:command generate invokable commands, would it still fallback to standard command if invokable commands aren't supported? I ask because these permutations can add up too.

[GromNaN]

Here are the open PRs that fall outside the new scope (to be closed):

Custom templates / paths / namespaces

• add customizable templates path #1710 add customizable templates path
• Customize template inherited #1672 Customize template inherited
• function to change the name path of the template Template.tpl.php #562 function to change template name path
• Configuration for custom namespaces #378 Configuration for custom namespaces

Extensibility / scaffolding / pluggability

• [RFC][WIP] add scaffolding system (make:scaffold) #1085 [RFC] scaffolding system make:scaffold
• [make:*] interactivly install composer dependencies #1466 interactively install composer
  dependencies
• [make:*] Fluent setters bundle configuration option #436 Fluent setters bundle configuration
  option

Edge-case options / personal preferences on existing makers

• [make:entity] Allow specify the table name #1730 make:entity specify table name
• Allow make:entity specify the table name #1635 make:entity specify table name
  (duplicate of [make:entity] Allow specify the table name #1730)
• Make:entity: Add question about unsigned integer #1661 make:entity unsigned integer question
• [make:entity] default value #1558 make:entity default value option
• [WIP][POC]: make:entity - adding support for multiple entity managers and mappings #1119 make:entity multiple entity managers
• [make:registration-form] Add hash_property_path option to PasswordType #1555 make:registration-form add
  hash_property_path option
• [make:security:form-login] no interaction for make:security:form-login #1595 make:security:form-login no-interaction
  option
• [make:security:custom] no interaction for make:security:custom #1594 make:security:custom no-interaction
  option
• Make Crud - Change field name appearance #544 make:crud change field name appearance
• WIP - [make:reset-password] handle multiple entities #1527 make:reset-password handle multiple
  entities
• [ResetPassword] add api platform support #798 ResetPassword API Platform support

New niche makers

• [make:doctrine:listener] Add maker for Doctrine event/entity listeners #1704 make:doctrine:listener
• [make:decorator] Add new maker to create decorator #1613 make:decorator
• [make:event] Add command for making Event class #1574 make:event
• feat: add make:form-extension command #1218 make:form-extension
• [DTO] Add new make:dto command #303 make:dto
• [make:security:json-login] WIP #1246 make:security:json-login (WIP)

Opinionated code shape changes without clear best-practice consensus

• [make:webhook] generate final classes #1637 make:webhook generate final classes

Borderline (could go either way depending on whether the maintainers consider the change a
"new recommended default" rather than an option):

• [make:command] Update command generation to support invokables and interactively ask for arguments and options #1750 make:command invokable + interactive
  args
• [make:validator] Add --target option that allows restricting automatically where the constraint class can be used #1744 make:validator --target option
• [make:user] add class name for UniqueConstraint #1722 make:user UniqueConstraint class name

Note: #1746 (make:command invokable by default) is in scope, it changes the default rather
than adding an option.

[GromNaN]

Within this new scope, if we have make:command generate invokable commands, would it still fallback to standard command if invokable commands aren't supported? I ask because these permutations can add up too.

I would choose to support only the latest LTS version (currently 7.4), to avoid putting too much pressure on upgrading PHP and the installed packages for newcomers, while making it easier to adopt the latest features in the generated code.
For the make:command example, that means we remove the extends Command version of the generated code; but we can't use Symfony 8.1 Improved Console Input

[stof]

I agree with @GromNaN here. Changing the default code of a maker should happen only once that new code is available in LTS. And dropping support for the old LTS allows to simplify the maintenance (projects stuck on the old LTS can stick to the last release of the bundle supporting it).

A new maker for a whole new feature might rely on non-LTS feature (i.e. we can add new makers for new released features even if they are not yet part of the LTS), with a check for the compatible version of dependencies.

[GromNaN]

MakerBundle: existing makers status vs. new scope

This report reviews every maker currently shipped by MakerBundle against the new scope (target newcomers, generate best-practice code, minimal configuration, latest LTS only, no extensibility, no edge-case options).

Status legend:

• in-scope the maker fits the new scope as is, only marginal cleanup needed
• needs-trim in scope but options or code branches should be reduced
• reconsider may not fit the new scope; needs a decision
• drop-candidate likely to be removed or moved elsewhere

Maker	Status	Rationale	Action to fit scope / drop
MakeCommand	in-scope	Simple template, useful for newcomers.	Switch default to invokable command (#1746). Drop the non-invokable fallback once LTS supports it.
MakeController	in-scope	Core scaffold.	Keep single recommended shape. Reject options that only tune style.
MakeForm	in-scope	Core scaffold.	Keep; align with current form best practices.
MakeVoter	in-scope	Small and stable.	Keep as is.
MakeSubscriber	in-scope	Straightforward event subscriber.	Keep as is.
MakeListener	in-scope	Companion to Subscriber, event autodiscovery adds value.	Keep, verify all branches still needed.
MakeMessage	in-scope	Generates message + handler, aligned with Messenger docs.	Keep.
MakeMessengerMiddleware	in-scope	Tiny, correct.	Keep.
MakeSchedule	in-scope	Matches current Scheduler component.	Keep.
MakeWebhook	in-scope	Follows Webhook component.	Consider making generated classes final by default (see #1637) as a recommended shape, not an option.
MakeTwigExtension	in-scope	Minimal.	Keep.
MakeTwigComponent	in-scope	Aligned with ux-twig-component.	Keep.
MakeStimulusController	in-scope	UX Stimulus scaffold, non trivial but well contained.	Keep, watch for option creep.
MakeSerializerEncoder	in-scope	Minimal template.	Keep.
MakeSerializerNormalizer	in-scope	Minimal template.	Keep.
MakeValidator	in-scope	Minimal.	Adopt --target (#1744) only if we consider it a recommended default; otherwise reject.
MakeUnitTest	in-scope	Minimal.	Keep.
MakeFunctionalTest	needs-trim	Overlaps with MakeTest.	Merge into MakeTest or delegate to it and remove the separate command.
MakeTest	needs-trim	Umbrella command that already covers unit / integration / functional.	Consolidate MakeUnitTest and MakeFunctionalTest here to reduce duplication.
MakeFixtures	in-scope	Minimal, common newcomer need.	Keep.
MakeDockerDatabase	reconsider	Docker Compose scaffolding is opinionated and outside the core Symfony concern.	Decide: keep as convenience for newcomers, or drop and defer to Symfony recipes and Docker Compose docs.
MakeMigration	in-scope	Thin wrapper over doctrine-migrations.	Keep.
MakeEntity	needs-trim	Largest and most complex maker. Combinatorial options are the root of the maintenance pain called out in the scope discussion.	Freeze the option surface. Reject new options (#1730, #1635, #1661, #1558). Consider extracting advanced relationship editing to a coding agent skill and keeping only the create/update happy path.
MakeCrud	needs-trim	Second most complex, tied to MakeEntity output.	Keep the single recommended layout, reject field-appearance options (#544) and route conflict options (#922).
MakeUser	in-scope	Core security setup.	Keep. Reject niche options (#1722) unless they become defaults.
MakeAuthenticator	needs-trim	Large legacy command superseded by Security/MakeFormLogin and Security/MakeCustomAuthenticator.	Decide whether to deprecate in favour of the two Security/* makers, or clearly document the split.
Security/MakeFormLogin	in-scope	Matches current recommended auth flow.	Keep. Reject #1595 (option to skip interaction).
Security/MakeCustomAuthenticator	in-scope	Small, focused.	Keep. Reject #1594.
MakeRegistrationForm	needs-trim	Very large; depends on MakeEntity + MakeUser output.	Reduce configurability. Freeze on the recommended shape from the latest LTS. Reject #1555, #1723 unless adopted as default.
MakeResetPassword	needs-trim	Similar profile to MakeRegistrationForm.	Same treatment. Reject #1527 (multi entity) and #798 (API Platform).

[javiereguiluz]

Jérôme, I love this proposal. I agree 100% on it. Thanks a lot for your work here and I hope others agree so we can start closing all those issues/PRs out of the scope. Thanks!

[kbond]

I love this!

I think this new scope should have the following rules also:

• Exclude makers that likely aren't used by beginners (ie make:authenticator)
• Exclude makers that have a flex recipe that is enough (ie make:schedule)
• Exclude makers that realistically are only run once (ie make:reset-password)

Here are my opinions on the current list of makers:

• MakeSubscriber: isn't the best practice to always use listeners now? Maybe we should drop in favor of MakeListener?
• MakeMessengerMiddleware: imo this is super rare to need
• MakeSchedule: flex provides a default recipe, rare to need multiple schedules
• MakeTwigExtension: should upgrade to the attribute method?
• MakeXTest: I believe the idea was to consolidate into the single make:test
• MakeAuthenticator/MakeCustomAuthenticator: rare/advanced need
• MakeFormLogin: single use
• MakeResetPassword: single use
• MakeRegistrationForm: single use

[GromNaN]

• See Bump minimum Symfony version to 7.4 and PHP 8.2 #1803

[GromNaN]

Thanks for the extra rules. I would refine the target audience a bit: the bundle is for developers who are new to a given Symfony feature, not only for absolute Symfony beginners. From that angle, "single-use per project" is not the same as "low value": that single time is exactly when the developer is learning the feature and benefits the most from a working skeleton.

Applied to the list:

• Keep make:messenger-middleware, make:schedule, make:authenticator, make:security:custom, make:form-login, make:reset-password, make:registration-form. All of them are entry points into an advanced feature. The Flex recipe for Scheduler, for instance, only wires the config; it does not give a task handler to learn from.
• Drop make:subscriber in favor of make:listener. Two ways to do the same thing, and #[AsEventListener] is the current recommended shape.
• Migrate make:twig-extension to the #[AsTwigFilter] / #[AsTwigFunction] attributes rather than dropping it.
• Consolidate make:unit-test and make:functional-test into make:test (already in the needs-trim row).

So the exclusion rule I would adopt is narrower: drop makers whose output is fully covered by the Flex recipe or that duplicate another maker, but keep the ones that scaffold a working example of a feature, even if a project only runs them once.

This scope is not set in stone: if a better way to scaffold projects emerges, either through richer Flex recipes or through another mechanism, we can revisit it and shift more responsibility away from MakerBundle.

I updated the README scope section accordingly.

[kbond]

Missed this comment, I agree with you.

Dropping the single-use maker's is too big a leap currently as we don't have an alternative yet.