- Is gnugat/wizard-bundle compatible with Laravel?
- No. gnugat/wizard-bundle is a Symfony 2 bundle built on Symfony's Kernel and Bundle contracts, registered in app/AppKernel.php and run through app/console, none of which exist in Laravel. It ships no Laravel service provider, facade, config merge, or Artisan command, so no Laravel version is supported. Dropping it into a Laravel app would fail immediately or install silently and do nothing.
- Can I install gnugat/wizard-bundle in a Laravel project with Composer?
- You can run composer require, but the package will not function in a Laravel application because it depends on Symfony 2 bundle registration and app/console rather than Laravel package discovery and the container. Bridging it would require custom glue around a deprecated dependency, which is strictly negative value. If the originating request assumed a Laravel drop-in, re-scope it before it reaches a sprint.
- What does gnugat/wizard-bundle actually do?
- It is a Symfony bundle for building multi-step forms as reusable wizards. You define ordered steps as services with clear responsibilities, navigate forward and backward through a controlled flow, validate each step before advancing, and preserve wizard state across requests. Flow control is separated from form handling and integrates with Symfony forms and services.
- Is gnugat/wizard-bundle deprecated or still maintained?
- It is explicitly tagged [DEPRECATED] with guidance to use Symfony Flex instead. It has 22 stars, 0 dependents, a single maintainer, and an opportunity score of 0.25, and there is no security patch channel. Upstream fixes are not expected, so adopting it transfers full maintenance ownership to you on day one.
- Does gnugat/wizard-bundle work with modern Symfony and Symfony Flex?
- The package's own deprecation notice directs users to Symfony Flex, and no compatibility with modern Symfony or PHP versions should be assumed. Any PHP or Symfony constraint claim must be validated inside a time-boxed proof of concept against an actual legacy application before it informs a decision. For modern Symfony, use Flex recipes rather than this bundle.
- How do I configure gnugat/wizard-bundle, and how does it validate wizard steps?
- Steps are defined as ordered services with clear responsibilities, and the bundle validates each step before the user can progress while preserving wizard state across requests. Configuration happens through Symfony bundle registration and app-level config, not Laravel's mergeConfigFrom() or publishes() tags. Forward and backward navigation is handled by the flow layer, separate from form handling.
- What are the alternatives to gnugat/wizard-bundle for multi-step forms in Laravel?
- In Laravel, use native primitives rather than this bundle: package auto-discovery via extra.laravel.providers and aliases, mergeConfigFrom() with publishes() tags instead of YAML edits, and a dedicated install command composing vendor:publish --tag=... calls. For the form flow itself, implement ordered steps as small, individually re-runnable actions in your own application code. For modern Symfony, Symfony Flex recipes replace the bundle.
- Can I reuse the wizard step orchestration pattern in a Laravel Artisan install command?
- Yes, conceptually. The only architectural overlap with a Laravel stack is a single CLI entry point orchestrating a sequence of small, reusable, individually re-runnable install steps. That maps cleanly onto php artisan <pkg>:install built on vendor:publish and Laravel Prompts. Treat the bundle as a case study, not a dependency.
- What are the production and security risks of using gnugat/wizard-bundle?
- Technical risk is high: the bundle is deprecated, has a single maintainer, 0 dependents, and no security patch channel. Its magic file-mutation behavior is hard to audit and hard to reverse, and it is likely incompatible with modern PHP and Symfony constraints. The risk is asymmetric, offering small setup savings against a future blocked framework upgrade.
- Should I use gnugat/wizard-bundle or build a first-party installer?
- Build a first-party installer. Measure your current install friction, such as steps, files, manual edits, and time-to-first-successful-request, against the cost of building it, then use the bundle only as a time-boxed design read of Command/InstallCommand.php and the Wizard/ step classes. The deliverable should be a requirements document, not code. If the target is a legacy Symfony app, ticket a Flex migration as tech debt and remove the bundle.