Mindy Bundle Laravel Package

Getting Started

First, verify the label before you plan anything. Despite being surfaced as a Laravel/PHP package, mindy/mindy-bundle is a Symfony-style bundle for the MindyPHP micro-framework. It ships no ServiceProvider, no facade, no publishable config, and no contracts targeting Laravel's container, HTTP kernel, router, or event dispatcher. php artisan vendor:publish and php artisan about will tell you nothing about it. If your only context is Laravel, budget ten minutes to confirm this on composer.json and the bundle class before you spend a day trying to make it fit.

Minimal steps to actually look at it:

1. composer require mindy/mindy-bundle in a scratch repo, never the product monorepo — then run composer show mindy/mindy-bundle --tree to see exactly which Mindy components (mindy/config, mindy/controller, mindy/router, mindy/orm, mindy/view) you just pinned.
2. Read vendor/mindy/mindy-bundle/DependencyInjection/Configuration.php and the bundle class itself. With 1 star, 0 dependents, and no documentation, that file is the authoritative specification — more useful than the README.
3. Grep Resources/config/*.xml|yaml for tags and service IDs to build your own map of what gets registered.
4. Check require.php in composer.json before you commit to anything — Mindy originates from the PHP 5.x/7.0 era and forward compatibility with modern PHP is unverified.

First use case — and it is not a feature. The realistic first use case for a Laravel developer is source study, not integration: read how the bundle wires services via a config tree, then port that pattern into a ServiceProvider of your own on top of Laravel-native primitives. If you genuinely must run Mindy code, the only defensible first use case is an isolated sidecar (a CLI invocation or queue worker in a separate process) — never a second kernel inside the Laravel request lifecycle.

Implementation Patterns

Pattern A — read it, don't run it (default recommendation). The bundle's value to a Laravel shop is its config-first wiring convention: a Configuration tree mapping 1:1 onto plain-array constructor arguments. Mirror that in Laravel rather than adopting the code:

// app/Providers/MindyStyleServiceProvider.php — pattern borrowed, not the package
$this->app->singleton(Connection::class, fn ($app) => new Connection(
    config('database.connections.mysql')
));

This gives you the design benefit at zero bus-factor cost.

Pattern B — subprocess isolation (if you must execute Mindy code). Keep Mindy in its own process and communicate over stdin/stdout or a queue. Laravel stays the only kernel in the HTTP path; the Mindy app runs as a console command invoked via Symfony\Component\Process\Process. This costs a process hop per call but avoids autoload collisions, duplicate container semantics, and parallel Request/Response abstractions entirely.

Pattern C — bridge provider (last resort, high cost). A ServiceProvider that resolves Mindy services out of Mindy's container and registers them into Laravel's:

$this->app->singleton('mindy.container', fn () => require base_path('mindy/bootstrap.php'));
$this->app->bind(SomeMindyService::class, fn ($app) => $app['mindy.container']->get(SomeMindyService::class));

Every adapter you write — container, router, middleware, request/response — is bespoke glue owned entirely by you, written against undocumented internals with no downstream consumers to validate the surface area. Price this before you start.

Pattern D — migration inventory (the genuinely useful pattern). If you own a legacy Mindy estate, use the bundle's config tree as your porting checklist. Each key in Configuration.php maps to a responsibility — routing, DI, dispatch, ORM, view paths — and each maps to a Laravel/Symfony equivalent. Port feature-by-feature. Do not integrate deeper; migrate off.

Reuse the existing PDO connection. If Pattern B or C is in play, feed Laravel's connection config into Mindy's ORM rather than opening a second pool. Two independent connection managers in one deployment is a debugging tax with no upside.

Pin to a commit SHA. Treat the current commit as a permanent snapshot. There is no versioned upgrade path and no compatibility guarantee.

Gotchas and Tips

• The catalog is wrong, and it matters. This is a Symfony bundle from the MindyPHP ecosystem, not Laravel. If your internal package catalog feeds Laravel suggestions that are actually Symfony artifacts, fix the classification before it burns evaluation cycles across the team.
• No ServiceProvider means no Laravel lifecycle hooks. No deferred providers, no booting/booted callbacks, no facade resolution. Anything you expect from Illuminate\Support\ServiceProvider is absent.
• Namespace and type collisions are the most likely runtime failure. Illuminate\Http vs Symfony\Component\HttpFoundation vs Mindy's own abstractions, plus duplicate container semantics. Coexistence requires strict process isolation or a Composer replace strategy — both add operational surface.
• Debugging has no external corpus. No Stack Overflow answers, no tutorials, no blog posts. Your debugging loop is debug:config mindy, debug:container --tag=mindy, and reading Resources/config/*.xml|yaml directly. Every question becomes an internal investigation.
• Silent breakage on PHP upgrade is the most probable failure mode, because there is no upstream to patch it. Add a CI job that boots the Mindy sidecar on every PHP version bump.
• No security-response channel. Low download volume means low external scrutiny and no visible CVE pathway. Vendor the code, run your own review, and track deprecations yourself.
• Extension points are internal, not a public contract. Semver discipline is unknown, so subclassing or decorating bundle services locks you to the exact commit you read.
• Budget the ownership, not the license. MIT clears procurement trivially; the real cost is a standing, permanent allocation for a component that delivers no differentiating capability. Assign a named owner and record the decision as "rejected on maintenance and ecosystem grounds" if the use case is anything customer-facing.