Maker Bundle Laravel Package

Getting Started

composer require --dev twc/maker-bundle

It is a thin wrapper over symfony/maker-bundle, so the prerequisites are already what you have: a Symfony app with MakerBundle installed and a writable src//templates/. There is no Flex recipe and the package has almost no adoption, so expect to register it by hand:

// config/bundles.php
Twc\MakerBundle\TwcMakerBundle::class => ['dev' => true, 'test' => true],

Then confirm the bundle is actually hooking into the generators before you rely on it:

php bin/console list make
php bin/console make:controller --help   # look for --context in the options list

Where to look first, in this order:

1. vendor/twc/maker-bundle/src/DependencyInjection/Configuration.php — this is the authoritative list of config keys. Whatever the README says, the config tree is the truth.
2. The compiler pass / command decorator in src/ — this tells you which make:* commands are wrapped and how the context is resolved (service argument, container parameter, or option injected into the command).
3. vendor/symfony/maker-bundle/src/Resources/skeleton/ — the template tree the package will be redirecting; your context directories mirror this structure.

First real use case: add a second context so a subset of generators emit your house-style skeletons instead of the stock ones.

# config/packages/twc_maker.yaml  (keys may differ — check Configuration.php)
twc_maker:
    default_context: app
    contexts:
        app:  '%kernel.project_dir%/templates/maker/app'
        api:  '%kernel.project_dir%/templates/maker/api'

php bin/console make:controller Api\\HealthController --context=api

If the generated file looks byte-for-byte like stock MakerBundle output, the context is not being picked up — go back to step 2.

Implementation Patterns

Per-context skeleton overrides. The intended workflow is: copy only the skeletons you care about out of vendor/symfony/maker-bundle/src/Resources/skeleton/ into templates/maker/<context>/, leave the rest absent, and let anything you did not override fall through to the original. Keep the directory in VCS — these are first-class project files, not vendor artifacts.

Multi-module / multi-tenant scaffolding. The strongest day-to-day use is a modular or layered app where admin, api and public code differ in base class, attributes vs. YAML routing, and namespace. Define one context per module, run the generator with the matching --context, and get a controller that is already in the right namespace with the right #[Route] prefix.

Pin the default per project. Setting default_context in config/packages/dev/twc_maker.yaml means the everyday make:entity / make:form / make:controller calls need no flag at all; you only type --context= when stepping outside the norm. This is the difference between "used daily" and "forgotten after week one".

Language-level contexts. A legacy context whose skeletons use docblocks and no constructor promotion is a genuinely useful pattern when one app has to support an older PHP runtime than the rest of the estate. Same trick for PHPUnit vs. Pest test skeletons.

Scripted scaffolding. Because the context is a CLI option, it composes with shell scripts and Composer scripts:

"scripts": {
    "make:module": [
        "@php bin/console make:entity --context=api",
        "@php bin/console make:controller --context=api"
    ]
}

Pair it with MakerBundle's own maker.yaml. root_namespace and your context namespace must agree; if you set root_namespace: App\Api for a run, use the api context, otherwise you generate correctly shaped code in the wrong namespace. Consider a small test that asserts the generated class FQCN matches the directory.

Gotchas and Tips

• Version fragility is the headline risk. Wrapping MakerBundle means re-declaring or decorating every command it ships. MakerBundle adds and renames commands and options between minor releases, so pin symfony/maker-bundle explicitly and re-run a generation smoke test after every upgrade. With 13 stars and zero dependents, you are effectively the QA team.

• Not every command is wrapped. Custom make:* commands from other bundles, and any MakerBundle command added after this package's last release, will reject --context with "The --context option does not exist." Check bin/console make:foo --help before assuming.

• Silent fallback on a missing skeleton. If a context directory or a specific template is absent, behaviour depends on the resolver: it may fall back to the stock skeleton (harmless but confusing) or throw a path-not-found. When a generated file looks wrong, -vvv the command and check which path was read.

• Clear the cache after editing config. Context paths are compiled into the container. bin/console cache:clear after touching twc_maker.yaml, or you will debug a phantom.

• Use %kernel.project_dir%, not relative paths. Relative skeleton paths resolve against the CWD and break the moment someone runs console from a subdirectory or a Makefile.

• Verify the wiring directly rather than guessing:

  php bin/console debug:container --tag=console.command | grep -i make
  php bin/console debug:config twc_maker
  

  debug:config will tell you instantly whether your YAML keys match the actual configuration tree.

• --no-interaction in CI. Generator commands prompt for names, namespaces and formats; a scaffolding step in CI will hang without it. Combine with explicit --context so the generated output is a fixed function of the repo, not the environment.

• Do not blind-commit the diff. A context change can alter the namespace and the base class of files that already exist; run make:* into a scratch branch and review before merging.

• Extension points, in increasing order of effort: add another context directory; override a single template for one command; decorate the bundle's own decorator to add a derived option (e.g. --context=api --with-tests); or, if the wrapper lags a MakerBundle upgrade, copy its context-resolution logic into a small local bundle — the concept is a dozen lines of config plus a path resolver, and you will own the upgrade path.

• Maintenance signal. Zero dependents and a low activity score means treat this as a vendored convenience, not infrastructure. If the pattern proves valuable, budget a half-day to fork it locally; you will spend that time on upgrade breakage anyway.