- Is mindy/mindy-bundle a Laravel package?
- No. It is a Symfony-style bundle that integrates the MindyPHP platform into Symfony applications, and it ships no Laravel service provider, facade, publishable config, or contracts targeting Illuminate components. Installing it in a Laravel application registers nothing with Laravel's container, router, HTTP kernel, or event dispatcher. Treat it as a Symfony and MindyPHP dependency rather than a Laravel one.
- How do I install mindy/mindy-bundle with Composer?
- Run composer require mindy/mindy-bundle, then register the bundle in your Symfony bundles.php or kernel bundle list. Installation itself is trivial; everything after that is bespoke wiring of Mindy's configuration, routes, and templates into your project. There is no php artisan vendor:publish step because the package is not built for Laravel.
- Does mindy-bundle register a Laravel service provider or facade?
- It does not. The package targets Symfony's bundle system and MindyPHP's own bootstrapping rather than Illuminate\Support\ServiceProvider or the Laravel facade base classes. Making it work in Laravel would require hand-written bridges between Mindy's container and Laravel's container plus adapters for routing, middleware, and request and response types. That glue would be owned entirely by you and written against undocumented internals.
- Which PHP and Laravel versions does mindy/mindy-bundle support?
- The package declares Symfony compatibility, not Laravel version constraints, so there is no supported Laravel version matrix to check. Mindy originates from the PHP 5.x and 7.0 era and modern PHP compatibility is unverified, so confirm the php constraint in composer.json and the latest tagged release date before adopting. The safe assumption is that it is not tested against current Laravel releases.
- What is actually inside the Mindy Bundle?
- The bundle packages Mindy's core components into a single dependency and registers services, configuration, routes, templates, and asset integration using Symfony bundle conventions. It is a thin integration layer around MindyPHP rather than a standalone framework. Read the bundle class plus its extension and configuration files first, because those determine whether any component is extractable for reuse.
- Can I run Mindy and Laravel in the same application?
- Technically yes, but you would end up with parallel containers, parallel HTTP abstractions, and duplicate dispatch paths. Laravel uses Illuminate\Http types while Mindy and Symfony-style code use their own request and response objects, so every boundary needs an adapter. That coexistence pattern is generally considered an anti-pattern and is better solved by choosing one framework.
- Is mindy/mindy-bundle actively maintained and safe to depend on?
- It is a single-maintainer project with a small dependent count and no publicly visible release cadence or security disclosure process, which means low external scrutiny. The MIT license is permissive and commercially safe, so the risk is neglect rather than legal exposure. If you adopt it, pin a known-good version and be prepared to vendor or fork it.
- Does mindy-bundle have a test suite covering the request lifecycle?
- There is no well-documented test suite, and coverage of the request lifecycle is not something you should assume. Verify by inspecting the repository for a tests directory, CI configuration, and assertions around routing, dispatch, and container resolution. Without that coverage, any integration you build has no downstream consumers to validate API stability.
- What should Laravel developers use instead of Mindy Bundle for content-driven apps?
- Use Laravel first-party primitives such as Eloquent, Blade, the HTTP kernel, routing, and middleware before reaching for an external micro-framework bundle. If you specifically want standalone components, source them directly from Symfony packages, which have broad maintainer support, documentation, and a predictable release cadence. Both routes avoid the maintenance liability of bridging two frameworks.
- How do I migrate a legacy Mindy application away from mindy-bundle to Laravel?
- Map the bundle's responsibilities, routing, dependency injection, dispatch, and configuration, onto Laravel equivalents and port them feature by feature rather than integrating deeper around the bundle. Keep the existing Mindy application in a legacy risk register while you migrate instead of treating the bundle as a modernization asset. Expect friction at the autoload and type level wherever Symfony HttpFoundation types meet Illuminate Http types.