Command Bundle Laravel Package

Getting Started

JMSCommandBundle is a Symfony2-era utility bundle that ships a handful of console commands intended to speed up early project scaffolding and development chores. It is not a runtime library — nothing in your application depends on it at request time, so treat it as a developer-tooling dependency (require-dev) rather than a production one.

Minimal setup:

1. Add the package to composer.json under require-dev (on very old Symfony 2.0 projects this was originally installed as a git submodule via deps/deps.lock).
2. Register the bundle in app/AppKernel.php:

   if (in_array($this->getEnvironment(), array('dev', 'test'))) {
       $bundles[] = new JMS\CommandBundle\JMSCommandBundle();
   }
   

   Registering it only in dev/test keeps the command surface out of production consoles.
3. Clear the cache and inspect what you actually got:

   app/console cache:clear
   app/console list jms
   

Where to look first:

• Command/ — the actual command classes; this is the whole value of the package.
• DependencyInjection/ — service wiring, and the place to look if a command is not appearing.
• README.md — the authoritative list of command names for the tagged version you installed (the command set changed across releases; don't trust blog posts).

First use case: run the scaffolding/init command from the jms: namespace against a fresh bundle or project skeleton, then delete the generated stubs you don't need. The realistic lifespan of this bundle in a project is "the first week of a new Symfony2 app," after which you remove it.

Implementation Patterns

Use it as a CLI, not an API. The intended workflow is purely app/console jms:<command> [args]. There is no meaningful public PHP API to call from your own code, so don't try to instantiate the bundle's command classes from services — you'll inherit console output coupling and InputInterface/OutputInterface requirements for no benefit.

Run it early, run it once. The typical sequence on a greenfield Symfony2 project:

app/console jms:<init-command> Acme DemoBundle   # scaffold
# edit generated files
app/console cache:clear
app/console list acme                            # verify wiring

Generated code is a starting point, not a maintained artifact — expect to rewrite namespaces, bundle names, and service ids.

Complement, don't duplicate, SensioGeneratorBundle. JMSCommandBundle predates and overlaps with sensio/generator-bundle (generate:bundle, generate:doctrine:entity, etc.). Pick one generator per concern and stick to it; running both against the same bundle produces inconsistent directory layouts and duplicate service definitions.

Custom commands follow the same convention. Because Symfony2 auto-discovers commands in <Bundle>/Command/*Command.php by naming convention, the natural pattern is to place your own commands alongside your bundle code and let the kernel register them — no service tag needed on Symfony 2.x. If you do register a command as a service, remember console.command tagging only exists from Symfony 2.4 onward; on 2.0–2.3 you must add it to the Application manually.

Container access inside commands. Any command extending ContainerAwareCommand gets $this->getContainer(). Reach for repositories and services there rather than embedding SQL or filesystem logic in the command body, so the command stays testable via CommandTester.

CI integration. If the bundle's commands are idempotent (scaffolding usually is), you can wire one into a build script for a smoke test that the console boots cleanly in the test environment. Avoid running generator commands in CI — they mutate source.

Gotchas and Tips

It is effectively abandoned. Last activity is Symfony2-era (PHP 5.3/5.4, Symfony\Component\Console 2.x APIs). It does not work with Symfony 3+, and composer require on a modern project will fail or drag in incompatible constraints. Its real value today is as a reference implementation — read Command/ for patterns, don't install it.

Commands silently missing. If app/console list doesn't show the jms: commands, check, in order: (1) the bundle is registered in AppKernel for the current environment, (2) you cleared the cache — Symfony2 caches the command list aggressively in prod, (3) the class name ends in Command and lives in the bundle's Command/ directory, (4) the bundle's DependencyInjection extension loaded without throwing (run with -vvv).

Old install method friction. Projects still on deps/deps.lock will not pick the package up from Composer; the bundle must be a git submodule with the autoloader registered in autoload.php. If you inherit such a project, migrating to Composer is usually a prerequisite before you can even evaluate this bundle.

Namespace and bundle-name assumptions. Scaffolding commands hard-code conventions (bundle short name → namespace mapping, Resources/config/, Controller/ layout). Renaming a generated bundle after the fact breaks the generated service definitions and routing imports — regenerate rather than rename.

Debugging output. Use app/console jms:<command> -vvv to see the underlying exception stack; the default verbosity swallows a lot when a generator fails mid-write. Also check file permissions — generators writing into src/ or app/config/ fail unhelpfully when the web/CLI user can't write.

Extension points. If you need to change generated output, the practical extension point is to copy the command class into your own bundle and edit it there — the bundle exposes little in the way of overridable templates or configuration compared to SensioGeneratorBundle. Check DependencyInjection/Configuration.php for the (small) set of configurable options before assuming something is hard-coded.

Version pinning matters. Because the command surface changed between releases and the package is unmaintained, pin an exact version in composer.json if you must use it at all, and record why in your project README so the next developer doesn't wonder why a dead dependency is present.