- Is mindy/orm a Laravel package?
- No. mindy/orm is a read-only subtree split of the ORM component from the Mindy PHP micro-framework, not a Laravel package. It ships no Laravel service provider, facade, config file, or publishing hooks. You can require it with Composer, but Laravel will not auto-wire it.
- How do I install mindy/orm in a Laravel application?
- You can install it with Composer, but installation alone does not integrate it with Laravel. There is no package discovery, no orm.php config, and no Illuminate integration in the manifest. A real setup requires a custom service provider, manual container bindings, and your own connection lifecycle wiring.
- Does mindy/orm support Laravel 10 or Laravel 11?
- There is no documented Laravel compatibility matrix and no illuminate/* constraints in the package manifest. The last release was in February 2018, so modern Laravel versions are not officially supported. Treat Laravel 10 or 11 compatibility as unproven until you run a smoke test on your target PHP and Laravel versions.
- Can I use mindy/orm and Eloquent in the same Laravel project?
- Technically yes, but it means running two persistence abstractions with separate models of connections, hydration, events, and transactions. The safe pattern is a strangler approach: hide Mindy behind repository interfaces, keep it in one bounded context, and never mix both ORMs inside a single transaction. For most Laravel codebases this adds complexity rather than removing it.
- Is mindy/orm maintained and safe for production?
- The package has had no release since February 2018, has very low adoption, and shows no active maintenance. It will not receive security advisories or compatibility fixes, so production use implies a fork-and-own obligation. MIT licensing is permissive, but unmaintained code is still a long-term risk.
- What PHP versions does mindy/orm support?
- The published package predates PHP 8.x and has no documented compatibility matrix for modern PHP runtimes. There are no declared constraints tying it to current PHP versions. Before considering it, run a strict-error smoke test on PHP 8.2 or 8.3 to catch signature changes and deprecations.
- How does mindy/orm compare with Eloquent or Doctrine?
- Mindy ORM is a lightweight Django-style alternative with its own query builder and entity mapping, not an Eloquent or Doctrine integration. Eloquent is Laravel's first-class ORM with migrations, factories, events, and Octane-safe connection handling; Doctrine and Cycle ORM have broader support outside Laravel. For a Laravel app, Mindy would sit beside Eloquent rather than replace it cleanly.
- Can mindy/orm use Laravel's database connections and transactions?
- Not natively. Laravel's DB layer already manages PDO connections, read/write splitting, and transaction callbacks, while Mindy's ORM expects its own connection object and transaction semantics. Bridging them requires a non-trivial adapter shim, and mixing both ORMs in one transaction is a correctness hazard. Keep transaction boundaries within one ORM per unit of work.
- Does mindy/orm support PostgreSQL, MySQL, and SQLite?
- Mindy historically targeted MySQL, and the package does not document a full SQL dialect compatibility matrix. PostgreSQL and SQLite parity are therefore unproven for your CI and production environments. Verify generated SQL against your actual database engine and version before relying on it.
- How should I test mindy/orm before adopting it?
- Start with a smoke test on your target PHP version, Laravel version, database engine, and PHPUnit version under strict error reporting. Exercise connection setup, hydration, relationships, and rollback behavior in a throwaway branch or bounded context. If the test passes, isolate it behind repository interfaces so you can remove it without touching application code.