- Is cortex/foundation still maintained?
- No. The repository is archived and explicitly described as the classic foundation, so there are no upstream security patches, Laravel compatibility updates, dependency maintenance, or community support. Treat it as legacy code and confirm ownership before adopting or forking it.
- Which Laravel and PHP versions does cortex/foundation support?
- The package does not publish a guaranteed current support matrix, and its archived status means compatibility is not maintained. Inspect composer.json constraints and run a Composer dependency audit against your target Laravel and PHP versions. A sandbox spike is the only reliable way to confirm resolution and service-provider boot behavior.
- How do I install cortex/foundation with Composer?
- Try composer require cortex/foundation in a throwaway branch, but treat installability as unproven until the dependency graph resolves. Check composer.json constraints, service providers, aliases, config files, and migrations. If Composer reports a why-not or an unresolved companion Rinvex package, stop and treat it as a no-go.
- What does cortex/foundation actually provide?
- It supplies the shared core of the Rinvex Cortex modular architecture: base contracts, service providers, and utilities for bootstrapping, configuration, and package integration. It is intended for modular Laravel monoliths that follow Rinvex conventions, not general-purpose Laravel applications. Companion Rinvex packages may be required for full functionality.
- Can I use cortex/foundation in a production Laravel app?
- Adoption is high risk because the package is archived and likely couples module loading, service providers, configuration, migrations, and companion packages. It has only 7 stars and 0 dependents, so community support is minimal. If you adopt it, fork under an internal namespace, pin a specific commit, assign an owner, and budget for security patching and framework upgrades.
- What are alternatives to cortex/foundation for modular Laravel?
- Consider maintained options such as Laravel package discovery, Composer path repositories, or nwidart/laravel-modules. These can support modular monolith patterns without depending on an archived foundation. Use Cortex Foundation as an architectural reference rather than a runtime dependency.
- Is cortex/foundation suitable for microservices or API-first apps?
- No, it is not a general-purpose Laravel package. It is conceptually relevant only if your product is a modular monolith using Rinvex conventions. API-first, microservice, serverless, and non-Rinvex architectures would require significant adaptation.
- How should I evaluate cortex/foundation before adopting it?
- Start with a reference-only path: extract patterns, contracts, and module-boundary conventions without installing the package. If reuse is justified, run a sandbox spike on your exact Laravel and PHP versions and audit transitive dependencies, licenses, migrations, and service-provider boot behavior. Then decide between reference-only, internal fork, or no-go.
- What is the migration path from Cortex Foundation classic?
- The repository is explicitly the classic foundation, and the context does not identify a maintained successor. Check whether a current Cortex release exists and whether its companion packages are available. If no maintained path exists, plan an internal fork or replace the foundation with maintained modular tooling.
- Why is cortex/foundation considered high risk?
- Archived status means no upstream security patches, Laravel compatibility updates, dependency maintenance, or community support. As a foundational package, failures can affect module loading, bootstrapping, configuration, and migrations across the application. That broad blast radius makes it a platform component you must own if adopted.