- Can I use mindy/application inside a Laravel app?
- No. mindy/application is not a Laravel package despite being listed in Laravel and PHP package directories; it is the bootstrap and kernel layer of MindyPHP and presumes sibling Mindy components and Mindy-specific contracts. Installing it alongside Laravel gives you two competing bootstraps and a confusing debugging surface, so for Laravel-centric teams it should be closed at intake.
- What exactly does mindy/application provide?
- It provides a lightweight application layer: a service container with autowiring and singleton bindings, environment-aware configuration loading, an HTTP kernel with a middleware pipeline, and service providers with a clear register and boot lifecycle. It is the foundation piece of MindyPHP, a small MVC micro-framework, not a standalone utility library.
- How do I install mindy/application with Composer?
- It is Composer-installable via composer require mindy/application, but the supported entry point is the Mindy monorepo because this repository is a read-only subtree split. Pin an exact version rather than a caret range since there is no evidence of semantic versioning discipline. For real use, install the full MindyPHP framework so sibling components are versioned together.
- Which PHP versions does mindy/application support, and does it follow PSR standards?
- The PHP version floor is not clearly documented, and PSR compliance (PSR-11, PSR-7, PSR-15) is not proven, so expect Mindy-specific contracts instead of standard interfaces. Verify the runtime floor and interface shapes against the monorepo before committing. Because it is not a Laravel package, there is no Laravel version compatibility matrix to check.
- What dependencies does mindy/application pull in?
- It presumes sibling Mindy components such as Container, Config, Routing, and Http, so the real dependency graph is the framework itself rather than this package in isolation. Check that every transitive Mindy component is published and tagged before relying on the split. Any integration effort is greenfield framework work, not dependency wiring.
- Is mindy/application production-ready?
- Adoption signals are weak: roughly one star, zero Packagist dependents, and no public consumers to inspect for idioms or pitfalls. There is a single maintainer, no visible security policy or advisory feed, and no LTS branch, which is high technical risk for production. Remediation also depends on an upstream pull request, a release, and a new subtree split, which is outside your control unless you fork.
- How does mindy/application compare to Laravel's kernel, Slim, Laminas, or Symfony MicroKernel?
- It occupies the same architectural slot as Illuminate\Foundation's application kernel but without Laravel's ecosystem, and it compares poorly to Slim, Laminas, or Symfony's MicroKernel on documentation, package ecosystem, and hiring pool. Those criteria dominate total cost of ownership for a small framework choice. Mindy is only a credible candidate if you have already decided to evaluate the whole framework.
- Can I migrate an existing Laravel app to mindy/application incrementally?
- No. A phased swap of Laravel's kernel for this component is not a realistic plan, since it replaces the application foundation rather than extending it. The only viable path is a greenfield service or bounded-context rewrite that boots MindyPHP end to end from the monorepo. That makes it a platform bet with multi-quarter implications rather than a sprint-sized dependency change.
- How do I report bugs or contribute patches to mindy/application?
- This repository is a read-only subtree split, which is a distribution artifact rather than a collaboration surface. Patches must go upstream to the Mindy monorepo, and the split can lag or drift from the source of truth. Confirm the monorepo's issue tracker and contribution model are active before planning any fixes.
- Does mindy/application follow semantic versioning, and should I pin versions?
- There is no evidence of semantic versioning discipline, and subtree splits commonly ship breaking changes alongside monorepo releases. Pin exact versions, review releases against the monorepo changelog, and assume no backwards-compatibility guarantees. If you need long-term stability, budget for owning a fork indefinitely.