Wurst Bundle Laravel Package

Getting Started

This is a Symfony bundle that renders ASCII-art würst (sausages) to the console. There is no Laravel service provider, no config publishing, and no Artisan command — so "getting started" in a Laravel codebase means copying the output, not installing the package.

Minimal steps:

# Do NOT `composer require` this in a Laravel app — it drags in symfony/framework-bundle.
# Instead, fetch the source as reference material only.
git clone https://github.com/marcw/MarcWWurstBundle /tmp/wurst-reference

1. Read the command first. Open the Command/ directory in the clone. The whole payload is a handful of hardcoded ASCII strings behind a Symfony Command subclass — you can absorb it in five minutes.
2. Create your own command — php artisan make:command WurstCommand — and paste the art into a resources/ stub or a const array, with a header comment citing the upstream repo, commit SHA, and license.
3. Guard it to local — early-return unless app()->environment('local'), so it never appears as an unexplained binary in a hardened production container.
4. First use case — a morale banner at the end of a deploy script or after composer install. That's the entire feature surface.

Where to look first: the command class, not the bundle registration. The bundle wiring (MarcWWurstBundle in bundles.php) is Symfony-specific and irrelevant to Laravel — ignore it entirely.

Implementation Patterns

Vendored command, not a dependency. The only defensible pattern. Ship app/Console/Commands/WurstCommand.php with the art inlined or in a stub file. No service provider, no bundle registration, no composer.json entry.

class WurstCommand extends Command
{
    protected $signature = 'wurst';
    protected $description = 'Prints some nice würst to your shell';

    public function handle(): int
    {
        if (! app()->environment('local')) {
            return self::SUCCESS;
        }
        $this->line(file_get_contents(resource_path('ascii/wurst.txt')));
        return self::SUCCESS;
    }
}

Composer lifecycle hook (local only). Wire it to post-install-cmd for developer delight, but keep it out of CI images where log noise matters. Make it non-blocking so a removed command never fails the build:

"scripts": {
  "post-install-cmd": ["@php artisan wurst || true"]
}

Artisan Command event listener. Laravel fires Illuminate\Console\Events\CommandStarting / CommandFinished. If you want the banner on every command, listen there and print only when $event->output->isDecorated() is true — piped logs and CI stay clean:

Event::listen(CommandFinished::class, function ($event) {
    if (app()->environment('local') && $event->output->isDecorated()) {
        // render your wurst
    }
});

As a teaching template. The highest-leverage use is studying bundle structure — a thin bundle, a small config tree, one command. It's a readable end-to-end example for onboarding docs or a "how a Symfony bundle works" workshop. That value is cultural, not functional.

Gotchas and Tips

• It's a Symfony bundle, not a Laravel package. The description's claim of Laravel compatibility is wrong. Composer install in a modern Laravel app (PHP 8.1+) will likely fight the archived package's Symfony 2.x/3.x / PHP 5.x/7.x constraints, forcing --ignore-platform-reqs — which silently degrades dependency resolution for the whole app. This is the primary reason to vendor rather than depend.
• Never composer require it into a production app that has a maintenance policy. It's archived, single-maintainer, zero dependents, with no security response channel. Treat the repo as read-only reference material.
• Non-ASCII output. The "würst" payload contains ü; Windows terminals and some CI log consumers render mojibake. Add a UTF-8 assertion in a test, or ship an ASCII-only fallback.
• Don't guess the Symfony command name. If you do spike an install in a throwaway container, run bin/console list | grep -i wurst — names aren't reliably documented.
• Guard on environment. Use $this->laravel->environment(['local']) early-return (or app()->environment('local')) so the command is inert on staging demos and production. Land it in an isolated, revertible PR — no bundling with other console tooling changes.
• Provenance matters. Add a comment in the command file and an entry in your internal package registry noting source repo, commit SHA, and fork date — otherwise the next person who greps for "wurst" will wonder why a copy exists. Budget roughly one engineer-day including license review and a single feature test asserting exit 0 and expected output.
• Extension point is your own command. Wrap or reimplement freely — there is no upstream API to preserve. If you want real CLI branding, use Laravel Prompts or Symfony Console styles so output stays consistent with the rest of your tooling.

The honest framing: this is a "copy the two files, delete the rest" candidate. Its value is developer morale, scoped as a small time-boxed novelty — not a platform decision.