Command Extra Bundle Laravel Package

Getting Started

This bundle targets Symfony 2.x and has been archived since early 2016, so treat the first hour as reconnaissance rather than a normal install.

1. Confirm your Symfony version first. The bundle's composer.json will constrain symfony/symfony (or the symfony/console / symfony/framework-bundle components) to a 2.x range. Run composer show pk/command-extra-bundle --all in a scratch project to see the constraint before you try to require it into a Symfony 3/4/5 app — Composer will refuse, and forcing it with --ignore-platform-reqs rarely helps because the Symfony Console API changed.
2. Install into a Symfony 2 project (or a throwaway one):

   composer require pk/command-extra-bundle
   

   If that fails, pin the last release tag that matches your Symfony minor version.
3. Register the bundle in app/AppKernel.php:

   $bundles = array(
       // ...
       new PK\CommandExtraBundle\PKCommandExtraBundle(),
   );
   

   Check the class name against vendor/pkruithof/command-extra-bundle/ — the namespace is the first thing to verify, since the repo description ("adds some flavor") tells you almost nothing about the API surface.
4. Read the source before the README. For an archived bundle with no dependents, src/ and any Resources/config/services.xml are more reliable than docs. Look for: a base Command class to extend, output/style helper methods, and any service tags that auto-register commands.
5. First real use case: take one existing command (e.g. a cache warmer or import job) and swap it onto the bundle's base command class, or wire in whichever output/helper service it exposes. Compare the console output before and after — that's the fastest way to see what "flavor" actually means here (typically formatted/coloured output, interaction helpers, or boilerplate reduction).

Implementation Patterns

Because the bundle is small and frozen, the useful patterns are the ones that work around an unmaintained dependency, not deep integration.

• Extend the provided base command. The most likely value in a bundle like this is a common base class (e.g. one that pre-wires the container, logging, or a styled output helper). Have your commands extend it rather than ContainerAwareCommand, then override configure()/execute() as usual. Keep the base class behind a thin abstraction of your own so you can swap it later.
• Route output through its helper service. If the bundle registers a style/formatting service, inject it rather than calling $output->writeln() directly. This is the seam to replace when you migrate.
• Wrap the dependency behind an interface you own. Given the archival status, define your own CommandStylerInterface (or similar) and let the bundle's helper be one implementation. That way a later move to Symfony's SymfonyStyle is a one-file change.
• Auto-registration via tags. If the bundle uses a compiler pass or a kernel.command tag convention, mirror it deliberately; don't rely on directory-scanning assumptions you haven't verified in services.xml.
• Migrate-in-place workflow for new commands: write new commands against Symfony Console's built-in SymfonyStyle (2.7+), and reserve the bundle only for legacy commands that already depend on it. This limits blast radius.
• Testing: run commands with CommandTester and assert on getDisplay(). This is bundle-agnostic and lets you verify the bundle's output helpers actually behave as expected before you rely on them.

Gotchas and Tips

• Archived since 2016 — no security or bug fixes. Do not introduce this into new projects. The realistic use is maintaining a legacy Symfony 2 app that already depends on it.
• Version ceiling is the biggest trap. Symfony Console changed constructor/interact()/run() signatures between 2.x and 3.x. A composer constraint written for 2.x will block Symfony 3+; check whether the bundle pins a component or the whole framework.
• PHP version drift. A 2016 bundle likely targets PHP 5.5–7.0. composer install on PHP 8 will surface deprecations (dynamic properties, each(), etc.) in the bundle itself.
• Sparse documentation is expected. With 0 stars and 0 dependents, assume examples are stale. Grep for class .*Command, setName, and any TaggedService/compiler-pass code to map the real API in five minutes.
• Config quirks: look in DependencyInjection/ for an extension that reads the pk_command_extra config key. If a config node exists but fails silently when missing, add it explicitly to config.yml rather than relying on defaults.
• Extension points are your exit ramp: if the bundle exposes a helper service or a base command, wrap those (not the whole bundle) and plan to replace them with SymfonyStyle, OutputFormatter, and standard Command subclasses on the next Symfony upgrade.
• Vendor-isolate it: mark it in your composer.json notes/README as legacy, and add a test command that exercises it so an upgrade failure surfaces immediately rather than at runtime.