Wizard Bundle Laravel Package

Product Decisions This Supports

• Re-scoping a mis-filed roadmap item. Any ticket describing gnugat/wizard-bundle as a Laravel package is wrong and should be corrected before estimation. It is a Symfony bundle, explicitly tagged [DEPRECATED] use Symfony Flex instead, with 22 stars and 0 dependents. The decision it actually supports is "close this evaluation," not "schedule this integration."
• Build vs. buy: build, and copy the successor's pattern rather than the predecessor's code. The problem the package attacked — composer require → register in kernel → append config → append routing → publish assets — was solved upstream by Symfony Flex on Symfony and by package auto-discovery plus vendor:publish on Laravel. There is no buy case at any price, including free.
• Installing friction as a first-class DX metric. The durable takeaway is the problem statement, not the artifact: how many steps, files, and manual edits sit between "composer require" and a working feature. Instrument this as time-to-first-successful-request and activation rate for any developer-facing surface we own.
• Roadmap input for a "one-command install" initiative. It justifies a bounded investment in an idempotent installer with dry-run/diff output, conflict detection, clear failure messages, and an uninstall path — precisely the gaps that made pre-Flex tooling fragile enough to be replaced.
• Reference design for our own package/scaffolder DX. The step model — small, composable, individually re-runnable mutations — is worth an engineer-day to read as a requirements source. The code is not.
• Framework-strategy hygiene. Flags any legacy Symfony surface in our portfolio for a Flex migration ticket, and confirms we should not standardize internal tooling on deprecated bundle conventions.

When to Consider This Package

• Only as a migration artifact. A legacy Symfony 2.x/3.x application already pins it in composer.json and we need to understand, contain, or remove it. Even then the correct action is a Flex migration, not continued use.
• As a bounded design case study. One engineer-day, zero runtime dependency, to extract installer requirements: idempotency, dry-run/diff, explicit failure messaging, uninstall.
• Look elsewhere in every other case. Symfony projects use Symfony Flex recipes. Laravel projects use Composer package auto-discovery in extra.laravel plus a custom php artisan <pkg>:install command built on Laravel Prompts and vendor:publish tags.
• Hard disqualifiers for anything customer-facing or long-lived: upstream deprecation notice, no maintenance activity, zero dependents (no community validation), no security patch channel, and unverified compatibility with modern PHP/Symfony. This combination is disqualifying regardless of the 0.63 score; the 0.25 opportunity score reflects it.
• Escalation trigger: if an existing production app still genuinely depends on it, that is not an adoption question — it is technical debt requiring a named owner and a dated migration timeline.

How to Pitch It (Stakeholders)

Bottom line: do not adopt. Extract the pattern, skip the dependency.

For executives: the proposal on the table was to cut setup friction by adding a third-party package. That package is a Symfony-only bundle, deprecated by its own maintainer in favor of Symfony Flex, with negligible adoption and no maintenance. Adding it would plant an unpatched dependency in our tree to save a few setup steps — a bad trade with a delayed cost. The useful insight survives without the code: developers abandon tooling that takes too long to become useful, so we invest in our own install experience instead. Cost of the recommended path is roughly two engineer-days; cost of the wrong path is a blocked framework upgrade six months from now.

For engineering: treat this as a reference implementation, not a library. Do not add it to any dependency graph. Spend a short spike reviewing how it decomposed multi-step bundle registration into a single command, and convert that into a requirements list for our own installer: idempotent steps, dry-run and diff output, explicit failure messages, and an uninstall path. On Laravel, implement with package auto-discovery (extra.laravel.providers, dont-discover for opt-out) plus a dedicated Artisan install command that composes tagged vendor:publish calls. On Symfony, standardize on Flex recipes and explicit Composer scripts. Track installer step count as a standing DX metric.

For the sponsor who raised this: the underlying concern is valid and we are acting on it — we are just acting on it with first-party mechanisms rather than a deprecated third-party bundle. We will report back with the installer requirements doc and a step-count baseline within one sprint.