- What is illuminate/foundation used for?
- illuminate/foundation is the application kernel and composition root of Laravel. It provides the container bootstrap, HTTP and console kernels, service provider and facade registration, configuration loading, environment detection, exception handling, and middleware and route plumbing. It is not an independent library; it is a read-only split of the laravel/framework monorepo that ties the other illuminate components together.
- Should I require illuminate/foundation directly in my Laravel app?
- No. Existing Laravel applications already get illuminate/foundation transitively by requiring laravel/framework, which is the supported consumption path. Directly pinning the split package risks class duplication and autoload-ordering conflicts if Composer resolves a different copy than the framework expects. Treat it as a platform component, not an independently installable dependency.
- How do I install illuminate/foundation?
- In practice you install Laravel with composer require laravel/framework, and illuminate/foundation arrives as part of that package set. The split repository is a build artifact and is not intended for direct installation. If you are evaluating the split itself, confirm that it is the official mirror under the Laravel organization rather than a lookalike namespace.
- Can I use illuminate/foundation without the full Laravel framework?
- No, there is no meaningful standalone contract. Its public surface assumes the entire framework is co-installed, including the container, support components, and HTTP and console layers. It is a poor fit for framework-agnostic PHP services, microservices, or teams trying to cherry-pick individual illuminate components without adopting Laravel.
- Is illuminate/foundation compatible with Symfony applications?
- It overlaps conceptually with Symfony's HTTP kernel and framework bundle but uses incompatible kernel contracts. You cannot swap it into a Symfony application as a drop-in foundation layer. Adopting it effectively means adopting Laravel as the platform.
- Which Laravel and PHP versions does illuminate/foundation support?
- The package has no independent semantic versioning; it moves in lockstep with laravel/framework. Its supported Laravel and PHP versions are whatever the matching framework major declares in its composer constraints. Always check the laravel/framework release requirements for the version you target rather than treating illuminate/foundation as separately upgradable.
- Why does illuminate/foundation have zero stars and zero dependents?
- Those figures reflect its status as a read-only split-repo mirror, not its adoption or quality. The real adoption signal is Laravel's install base, since every Laravel application uses this code through laravel/framework. Do not use the repository score as a risk input in either direction.
- Can I customize the Laravel kernel or bootstrap process?
- Yes, Laravel exposes kernel and bootstrap extension points, but this area is high-churn across major versions. Laravel 11 moved bootstrap/app.php to a fluent configuration API and relocated middleware and provider registration, so code that subclasses or decorates the kernel can break on upgrade. Prefer documented extension points and test custom bootstrappers against each Laravel major.
- Is illuminate/foundation production-ready and maintained?
- Yes, when consumed through laravel/framework, because it is the foundation every Laravel application runs on. Maintenance and security fixes flow through Laravel framework releases rather than through the split repository independently. Direct use of the split package is unsupported and should not be treated as a stable production integration path.
- What are alternatives to illuminate/foundation?
- The realistic alternative is a different platform: Symfony's HttpKernel and FrameworkBundle, or lighter PSR-7 and PSR-15 stacks such as Slim or Mezzio for framework-agnostic services. Within Laravel there is no substitute, because illuminate/foundation is the framework's composition root. Choosing it is a platform decision to run Laravel, not a package-level dependency choice.