micayael/commands-bundle
A Symfony bundle that provides a set of reusable console commands, helping you scaffold, inspect, and manage your application from the CLI with minimal configuration.
Install and register the bundle.
composer require micayael/commands-bundle
This is a Symfony bundle, not a standalone library, so it must be registered before any command appears:
app/AppKernel.php:
new Micayael\CommandsBundle\MicayaelCommandsBundle(),
config/bundles.php. If not, add it manually.Find out what you actually got — first. The package has near-zero adoption, so the docs and your installed version are the only sources of truth about command names. Do this before writing any workflow around it:
php bin/console list
php bin/console list | grep -i micayael # or whatever namespace the commands use
php bin/console help <command-name> # confirm args/options before scripting
First use case. Treat it as a scaffolding/utility bundle: pick one generation-style command (e.g. a CRUD/controller/entity generator) and run it against a throwaway entity in a scratch branch. Diff the output against what MakerBundle or your own skeleton produces. That single side-by-side tells you whether the bundle earns a place in your daily loop or is just a one-off curiosity.
Where to look first when something is unclear: read the command classes directly in vendor/micayael/commands-bundle/ — with a package this small and this undocumented in the wild, src/Command/*.php is the documentation. The configure() and execute() methods define every option and behavior you need.
Discovery-first workflow. Because command names are not guaranteed by public docs, keep a short cheat sheet in your repo (e.g. docs/commands.md) listing the verified command signatures for the pinned version. This prevents "works on my machine" drift when a teammate updates the dependency.
Scaffold-then-own. Use the bundle's generators as a bootstrap accelerator, then immediately commit the generated files and treat them as hand-owned code:
git checkout -b scaffold/order-crud
php bin/console <generate-command> --entity=Order # confirm flags via `help`
git add -A && git commit -m "scaffold: order crud from commands-bundle"
Once committed, you can refactor freely without depending on the generator again. This is the safest pattern for a low-maintenance dependency: extract value once, don't couple your runtime to it.
Wrap it in project scripts. Any command you run more than once should be encoded in a Makefile or Composer script so the invocation (and its flags) is reproducible:
{
"scripts": {
"scaffold:admin": "php bin/console <command> --force"
}
}
Use in CI for generation-drift checks. If the bundle generates code you commit, add a job that regenerates into a temp dir and diffs. Any diff means either the bundle version changed behavior or your skeleton drifted — both worth knowing:
php bin/console <command> --output-dir=/tmp/regen --no-interaction
diff -ru src/Generated /tmp/regen || echo "generation drift"
--no-interaction everywhere. Any command used in scripts or CI must be verified to run non-interactively. Run it once with -n locally and confirm it doesn't block on prompts — Symfony commands that call $this->ask() unconditionally will hang CI.
Override rather than fork. If a generated template or command behavior is wrong, prefer subclassing the command or overriding its template path (via bundle config or a service decorator) over patching vendor/. Patching vendor breaks on every composer update.
Pair with MakerBundle, don't replace it. On Symfony 4+, MakerBundle is the maintained, first-party path. Use this bundle only for the specific commands MakerBundle doesn't cover, and keep the rest of your scaffolding on MakerBundle so you're not depending on an unmaintained package for core workflow.
Version compatibility is the big risk. The description says "Symfony2+", but "2+" often means the code targets Symfony 2/3 APIs that were removed in 4/5/6/7 (e.g. ContainerAwareCommand, old getContainer() patterns, AppKernel assumptions). Before adopting:
composer.json in vendor/micayael/commands-bundle for the symfony/* version constraints.composer why-not symfony/framework-bundle <your-version> to see conflicts.Zero stars / zero dependents = zero safety net. Pin the exact version in composer.json ("micayael/commands-bundle": "1.2.3", no ^), and assume no bug fixes are coming. Budget for the possibility of forking it into your own namespace if it becomes load-bearing.
Bundle registration failures. If php bin/console list shows nothing, the bundle isn't registered, or the command classes aren't tagged. Confirm with:
php bin/console debug:container --tag=console.command | grep -i micayael
In Symfony 4+, missing autoconfiguration means commands silently don't appear.
Generators overwrite silently. Most scaffolding commands default to writing files without warning, or with a --force/--overwrite flag that bypasses prompts. Always scaffold inside a clean git worktree so git diff is your undo button. Never run a generator command against a dirty tree.
Interaction with existing code. Generated controllers/routes/entities may assume conventions that clash with your project (directory layout, namespace, service autowiring). Diff generated output against your existing style before committing; retrofitting a whole CRUD after the fact is more work than editing two files up front.
Debugging failures. Run with verbosity and no interaction to see the real error rather than a swallowed exception:
php bin/console <command> -vvv -n
Generator commands frequently fail on missing directories, missing write permissions, or an entity class that doesn't exist yet — the stack trace will point at the path it tried to write.
Extension points to know. For a bundle of this type, the usual customization surfaces are (a) subclassing the command class and registering your version, (b) overriding Twig/PHP templates via bundle config if the generator supports it, and (c) decorating services if commands are registered as services. Check the bundle's DependencyInjection/ folder for a Configuration class — if there's no Configuration.php, there is no config tree and (b) is off the table, so you're down to subclassing.
The honest verdict for day-to-day use: with no adoption, no ecosystem, and likely stale Symfony API usage, this is a "try it for one task, vendor the useful bits, move on" package — not something to build a repeatable team workflow on. If a command genuinely saves you an hour, copy the relevant command class into your own app's src/Command/ and drop the dependency; you keep the value and lose the risk.
How can I help you explore Laravel packages today?