Wurst Bundle Laravel Package

Product Decisions This Supports

This package does not support a feature or roadmap decision — it informs a dependency policy decision and a developer-experience budget decision. Framed honestly for a PM:

• Build vs. buy → build (i.e., copy). The entire product surface is a console command that prints hardcoded ASCII-art würst. There is nothing to buy. The PM decision is whether cosmetic CLI output warrants a third-party dependency in the lockfile. It doesn't: vendor ~20–60 lines into a project-owned command and keep the dependency graph clean.
• Dependency governance precedent. Adopting an archived, single-maintainer, zero-dependent, framework-mismatched package sets a bad precedent. The decision worth ratifying is a policy line: novelty/cosmetic packages are vendored, not depended upon. This package is a good concrete test case for that rule.
• Framework fit is a disqualifier, not a tradeoff. The brief says "Laravel/PHP," but this is a Symfony bundle — no Laravel service provider, no config publishing, no Illuminate integration. For a Laravel roadmap item, the only realistic path is reimplementation, which settles the adopt/reject question by itself.
• Developer experience / morale budget. The one legitimate use case is a low-cost easter egg: a banner on a deploy footer, an onboarding demo, a post-install gag. It should be scoped as a near-zero-effort cultural item, explicitly not roadmap work.
• Teaching and reference material. The code is small enough to read end-to-end, making it a useful example for "how a bundle is structured" in internal workshops — reference, not dependency.
• What it does not support: any user-facing product surface, CLI branding strategy, or platform/infrastructure decision. For those, use framework-native console styling (Symfony Console, Laravel Prompts) so output stays consistent and maintainable.

A fitting note for the pitch: in German, "Wurst" also means "doesn't matter" ("ist mir wurst"). The package is self-aware about its own priority level.

When to Consider This Package

Adoption criteria should be deliberately strict given the facts: archived, 60 stars, zero dependents, no maintainer, and Symfony-only wiring.

• Consider (as reference only) if you are on Symfony, want a one-off console easter egg, and are comfortable copying the art and command logic rather than requiring the package — with a named owner for the snippet going forward.
• Consider (as teaching material) if you need a minimal, readable example of Symfony bundle structure for onboarding docs or a workshop.
• Consider (dev-only, exact-pinned require-dev) only if a throwaway spike proves it clean-installs on your target PHP/Symfony versions, the command is container-free, and the license is clearly declared. Even then, vendoring is preferred.
• Do not consider if any of these apply: you need a maintained dependency; you have a security/license review gate; you run Laravel (no adapter exists); you require upstream support or issue triage; the output is user-facing; or your dependency policy excludes archived packages. All of these apply to a typical production Laravel app.
• Look elsewhere for real CLI branding or UX — use the framework's native console styling so output stays consistent and you don't ship a dead dependency.
• Watch for the specific failure modes before deciding: old php/symfony/* constraint ranges forcing --ignore-platform-reqs (which silently degrades resolution for the whole app), non-ASCII "würst" payload causing mojibake on Windows/CI log consumers, and unclear licensing on an archived repo.

The honest framing: this is a "copy the two files, delete the rest" candidate, not an install-and-pin candidate.

How to Pitch It (Stakeholders)

To executives: No business value, no cost, no risk — provided we don't add it as a dependency. It is a joke package that prints sausages to a terminal. Recommendation: treat it as inspiration, not infrastructure. There is nothing here to fund and nothing here that belongs on a roadmap. Approve as a five-minute team morale easter egg if desired; reject as a dependency in any application with a maintenance policy.

To engineering:

• It's a Symfony bundle, archived and unmaintained, 60 stars, zero dependents. The whole thing is ASCII art behind a console command. If you're on Laravel, there's no adapter — which settles it.
• If the team wants the gag, copy the art into a project-owned Illuminate\Console\Command (roughly a half-day including license review and a feature test), guard it to local, and cite the source repo/SHA/license in a header comment. Remove it from production images and the default command list.
• The real risks are hygiene, not runtime: an archived repo with no security response channel is exactly the profile we exclude from runtime dependency graphs; old constraint ranges may force --ignore-platform-reqs, poisoning the lockfile; non-ASCII output can mangle in CI/Windows logs. Vendoring under our own namespace collapses all three.
• Avoid symfony/framework-bundle ever appearing in a Laravel app because of a novelty command — that's the failure mode this decision prevents.

Bottom line: Approve as a five-minute morale easter egg if the team wants it, delivered as vendored, local-only, revertible code; reject as a dependency in any application with a maintenance policy. The package's own name is the most accurate summary of its priority — a small, time-boxed novelty, not a platform decision.