- Is mindy/orm-bundle a Laravel package?
- No. It is a Symfony bundle integrating Mindy ORM, registered through a Symfony/Mindy kernel and DI extension, not a Laravel ServiceProvider. Laravel resolves persistence through ServiceProviders and Eloquent, so the boot and container layers do not match. Treat any claim that it installs cleanly into Laravel as unverified until a spike proves service resolution.
- Can I use mindy/orm-bundle with Laravel?
- Technically possible only via a custom shim that emulates bundle registration, translates the config tree, binds service IDs, and reconciles Symfony polyfills and event-dispatcher semantics. That is an adapter with an ongoing upkeep bill, not a composer require. Cap evaluation at a 1–2 day read-only spike, then route the requirement to Eloquent or laravel-doctrine/orm.
- How do I install mindy/orm-bundle?
- It is installed via Composer and registered as a Symfony bundle in a Symfony kernel, with configuration handled through the bundle DI extension and YAML or XML service definitions. There is no Laravel package discovery or publishable config repository. For Laravel, installation alone does not provide a working persistence layer; you would still need a bridge.
- What Laravel versions does mindy/orm-bundle support?
- None are declared or tested. The package is a Symfony bundle with no observable Laravel support matrix, CI, or release cadence against Laravel versions. Each Laravel version bump would re-test any shim you build. Use laravel-doctrine/orm or Illuminate\Database for supported Laravel persistence.
- What is mindy/orm-bundle used for?
- It integrates Mindy ORM with Symfony, providing configuration-driven connections and mappings, entity and repository integration with Symfony services, query building through Mindy ORM APIs, and framework-native dependency injection and console support. It is positioned as a lightweight alternative to Doctrine for Symfony/PHP applications that need straightforward database mapping and querying. It is not designed for Laravel's container or Eloquent lifecycle.
- Is mindy/orm-bundle a good alternative to Doctrine for Laravel?
- No. It is a Symfony bundle alternative to Doctrine inside the Symfony/Mindy ecosystem, not a Laravel ORM. For Laravel, the maintained alternatives are laravel-doctrine/orm for data-mapper needs or the plain Illuminate\Database query builder. Adopting this bundle would require a custom adapter and fork-level ownership.
- How do I test mindy/orm-bundle in a Laravel app?
- Start with a throwaway Laravel app and attempt manual instantiation of the ORM core outside the bundle, logging exactly which classes fail without the Mindy kernel. Abort if most of them fail. Also check whether the Mindy kernel bootstraps static connection state, because unit tests and queue workers will behave differently from HTTP requests.
- What are the production risks of using mindy/orm-bundle with Laravel?
- Technical risk is high: 1 star, 0 dependents, composite score 0.005, and no observable CI, static analysis, PHP 8.x matrix, or release cadence. The MIT license makes forking legally trivial, but the realistic end state is owning a fork. Unresolved kernel and static connection state could also make queue workers and tests diverge from HTTP requests.
- Does mindy/orm-bundle support PHP 8.2 and 8.3?
- The provided context does not confirm it. The evaluation flags no PHP 8.x support matrix or CI proving constraints on 8.2 or 8.3. Check composer.json for the declared PHP constraint and ask the maintainer for CI evidence. Treat PHP version support as unverified until proven.
- What should I use instead of mindy/orm-bundle in Laravel?
- Use Eloquent for active-record persistence or laravel-doctrine/orm if you need a data mapper. Both are maintained and versioned against Laravel releases. If you only need query building, use Illuminate\Database. Document the decision so the same package is not re-evaluated next quarter.