Dto Generator Bundle Laravel Package

Getting Started

1. Install and register. Require the bundle with Composer, then confirm registration. Symfony Flex auto-registers bundles whose recipes exist; with 0 stars and no dependents there is likely no Flex recipe, so add it manually to config/bundles.php:

   SVB\DtoGeneratorBundle\SvbDtoGeneratorBundle::class => ['all' => true],
   

2. Find the actual entry points first. Do not guess the API from the README name. Run:

   php bin/console list | grep -i dto
   php bin/console debug:config svb_dto_generator   # adjust the alias to whatever debug:config suggests
   php bin/console config:dump-reference <alias>
   

   The command list and the dumped config reference are the authoritative docs for this package — treat them as the source of truth over any blog post.

3. Publish/inspect config. If the bundle ships a recipe-less default, dump the reference and place a minimal config in config/packages/. The two settings that almost always matter for a DTO generator are the output namespace and the target directory (e.g. App\Dto → src/Dto). Set those before generating anything so you never have to move files by hand.

4. First use case: kill a hand-written array shape. Pick one controller or message handler where you currently return array or pass array $data around. Generate a DTO for that payload, wire it in, and stop. This gives you a feel for the generated style (readonly properties? constructor promotion? attributes?) on a low-risk change before you roll it across the codebase.

5. Confirm autoloading. Generated files land under src/, which is already PSR-4 mapped, so a composer dump-autoload is usually unnecessary — but run it once after your first generation to rule out namespace mismatches.

Implementation Patterns

Generate, then own the code. A generator bundle's output is a scaffold, not a managed artifact. The healthiest pattern is: generate once into src/Dto, commit the result, and thereafter edit the DTO by hand. Reserve regeneration for new DTOs or throwaway experiments. If you find yourself re-running the command over existing files every sprint, you are fighting the tool — either the templates need customising or you should stop using the generator for that class of DTO.

Match the generator to a source of truth. DTO generators are most valuable when they derive from something already defined: a Doctrine entity, a JSON Schema, an OpenAPI spec, or a form. A DTO generated from an entity gives you a typed, framework-free projection for your API layer. A DTO generated from a schema gives you contract-first request objects. Wire the generator into the workflow at the point where the source changes, not as a separate chore — e.g. after adding an entity field, regenerate or hand-extend the corresponding DTO in the same PR.

Layer the DTO between transport and domain. The day-to-day payoff is a hard boundary:

final class CreateOrderRequest
{
    public function __construct(
        public readonly string $customerId,
        public readonly array $lines,
    ) {}
}

Controller deserialises into the DTO (Symfony's #[MapRequestPayload] or a serialiser), the handler takes the DTO, the domain entity is built inside. Once this shape is habitual, generated DTOs slot in naturally — the generator just saves you typing the constructor.

Customise templates instead of post-editing. If the bundle exposes template overrides via config or a templates/ directory (check config:dump-reference), copy the template into your app and adjust it once: add readonly, add your validation attributes, change the namespace style. Every subsequent generation then produces code that matches your house style, which is the difference between a generator you keep and one you delete after a week.

Pair with validation and serialisation attributes deliberately. Decide once whether DTOs carry #[Assert\*] and #[Groups] attributes, or whether validation lives in form requests / serialiser config. If the generator emits attributes you do not use, strip them in the template — noise in generated code trains reviewers to skim.

Batch generation for bulk migrations. When introducing DTOs to a legacy app, generate a whole directory in one pass, then review the diff as a single unit. Committing generated files in one "scaffold DTOs" commit keeps later hand-edits readable in history.

Gotchas and Tips

• Adoption risk is real and should shape your integration. Zero stars, zero dependents, zero score. This is a small in-house-style bundle. Before depending on it, read the generator source (it is typically a few hundred lines) so you can fork or vendor it if maintenance stops. Pin the version in composer.json and avoid ^ ranges that could pull breaking template changes.
• No recipe means manual steps. With no Flex recipe, expect to register the bundle and create config by hand; also expect the README to be the only documentation. Verify every command name against bin/console list rather than copying from the README, which may target an older Symfony version.
• Overwrite prompts and silent clobbering. Generators vary: some refuse to overwrite, some overwrite silently, some write .bak files. Test on a scratch DTO before running against a directory of hand-edited files. Commit or stash first — this is the single most common way to lose an afternoon.
• Namespace/directory drift. If you change App\Dto to App\DataTransfer in config later, previously generated files keep the old namespace. Generators rarely migrate existing files. Decide the namespace on day one.
• Cache after config changes. Symfony caches bundle config and container definitions. After editing the bundle's YAML, run php bin/console cache:clear — a stale container is the usual cause of "my config change did nothing."
• Debugging generated-code errors. When a generated DTO fails to autoload, the cause is almost always a namespace-to-path mismatch or a missing composer dump-autoload. Check composer dump-autoload -o output for classmap warnings.
• Do not put logic in generated DTOs. They will be regenerated or diffed against templates. Keep behaviour in mappers, factories, or the domain — DTOs should stay dumb data carriers so regeneration stays cheap.
• Extension points to look for. In rough order of usefulness: template override path, naming/namespace config, a base class or interface applied to generated DTOs, and events/subscribers around generation. If none of these exist, the fallback is to fork the bundle into src/ — for a generator this small that is often cheaper than lobbying upstream.
• Test the output, not the command. Add a single test asserting one generated DTO round-trips through your serialiser. That catches template regressions after a composer update far faster than reading changelogs — which, for a bundle this size, may not exist.