Wizard Bundle Laravel Package

Technical Evaluation

• Architecture fit — no as a dependency, yes as a case study. gnugat/wizard-bundle is a Symfony 2 bundle (GnugatWizardBundle), not a Laravel package. It depends on Symfony's Kernel/Bundle contracts, app/AppKernel.php, and app/console — none of which exist in Laravel. There is no service provider, facade, or Artisan command. Its only architectural overlap with a Laravel stack is conceptual: a single CLI entry point orchestrating a sequence of small, reusable, individually re-runnable install steps. That orchestration model maps cleanly onto php artisan <pkg>:install built on vendor:publish and Laravel Prompts, which is the pattern worth extracting.
• Integration feasibility — low. There is no viable path to drop this into a Laravel application. Integration would fail immediately (or worse, install silently and do nothing), and any attempt to bridge Symfony 2 bundle registration into Laravel's container would be custom glue around a deprecated dependency — strictly negative value. Feasible integration is limited to a one-engineer-day design read of Command/InstallCommand.php and the Wizard/ step classes to produce a requirements list for our own installer.
• Technical risk — high. The package is explicitly tagged [DEPRECATED] use Symfony Flex instead, has 22 stars, 0 dependents, a single maintainer, an opportunity score of 0.25, and no security patch channel. Upstream fixes are not expected. Adopting it would transfer full maintenance ownership to us on day one, and the "magic" file-mutation behavior is hard to audit, hard to reverse, and likely incompatible with modern PHP/Symfony constraints. Risk is asymmetric: small setup savings against a future blocked framework upgrade.
• Key questions.
  • Is the target application actually Laravel, or is this a legacy Symfony 2.x/3.x surface in disguise?
  • Does any application in our portfolio already pin this bundle in composer.json? (0 dependents suggests not, but our own trees are the only authority.)
  • What is the measured cost of our current install friction — steps, files, manual edits, time-to-first-successful-request — versus the cost of building a first-party installer?
  • Do we have a legacy Symfony surface that should be ticketed for a Flex migration independent of this evaluation?
  • Who owns the time-boxed reference spike, and what is the deliverable (requirements doc, not code)?
  • What PHP/Symfony versions does it actually constrain, and has anyone verified this rather than assumed it?

Integration Approach

• Stack fit. Laravel: not a fit at any version — do not add. Modern Symfony: use Symfony Flex recipes. Legacy Symfony 2.x/3.x: migration artifact only, treated as technical debt rather than a component. If the originating request assumed a Laravel drop-in, re-scope it before it reaches a sprint; the package cannot satisfy that requirement.
• Migration path. For a legacy Symfony app, inventory the current bundle installation ritual (require → register in AppKernel → append config → append routing → publish assets), replace it with Flex recipes plus explicit Composer scripts, then remove the bundle. For a Laravel app, do not migrate anything — instead map each wizard step onto the native primitive that already covers it: package auto-discovery via extra.laravel.providers / aliases, extra.laravel.dont-discover for opt-out, mergeConfigFrom() plus publishes() tags instead of appending YAML, and a dedicated install command composing vendor:publish --tag=... calls rather than templating edits into source files.
• Compatibility. Do not assume compatibility with anything. No Laravel version is supported at all. Any PHP/Symfony constraint claim must be validated inside a time-boxed proof of concept against an actual legacy app before it informs a decision. Absent that app, close the evaluation without a compatibility spike.
• Sequencing.
  1. Confirm the target framework and whether any repo already depends on the bundle.
  2. If legacy Symfony: open a Flex migration tech-debt ticket with an owner and timeline; do not scope new work on this bundle.
  3. If we want the pattern: run a one-engineer-day design spike and produce a requirements doc covering idempotency, dry-run/diff output, conflict detection, uninstall, and explicit failure messaging.
  4. Implement the Laravel equivalent as an Artisan install command on vendor:publish + Prompts + package discovery, hooked via post-autoload-dump → package:discover.
  5. Add install-step count and time-to-first-successful-request to the DX metric set.
  6. Record the evaluation as a documented no-go so the same proposal does not resurface next quarter.

Operational Impact

• Maintenance. Zero leverage. Deprecated status means no upstream fixes, no compatibility patches, and no security advisories. Production use would require us to own, patch, and eventually replace a fork — an unbounded commitment for a few saved setup steps. As a reference artifact, maintenance cost drops to zero once the spike closes.
• Support. Weak. Twenty-two stars and zero dependents mean no community validation, few public integration examples, and no realistic path to external help. MIT licensing is permissive but does not offset abandonment risk. Internal engineers would be the only support channel, and only for a system nobody chose to learn.
• Scaling. Not a runtime scaling concern — this is install-time tooling and has no bearing on request throughput or data volume. The indirect scaling impact is real, though: fragile onboarding compounds per environment and per team, and inconsistent setup produces the class of "works on my machine" incidents that consume senior-engineer hours disproportionately. The counter-position is that a well-built idempotent installer is a scaling multiplier for every team that onboards afterward — which is the argument for building, not buying.
• Failure modes. Broken or partial install scripts; bundle registration conflicts; hidden and unauditable filesystem mutations; version constraint failures on modern PHP; silent no-op behavior on Laravel that misleads rather than errors; and — the one that matters strategically — a blocked framework upgrade surfacing months later with no clean removal path. Each of these is worse than the manual steps it replaces, because it fails without a clear signal.
• Ramp-up. Small code surface, high context burden. Reading the bundle requires Symfony 2 bundle/installer knowledge that most of our engineers do not have and should not acquire. Budget a single discovery spike, not a delivery workstream.
• TPM recommendation. No-go for adoption in any Laravel or modern Symfony context. Extract the problem statement — developers abandon tooling that takes too long to become useful — and fund a first-party one-command installer with dry-run, uninstall, and conflict detection. Direct Symfony teams to Flex. If a legacy application still depends on this bundle, convert it to a tracked technical-debt item with a named owner and a migration deadline. The cost of ignoring this assessment is a quiet, low-effort "just add the package" decision that plants an unmaintained dependency in our tree.