Weave Code
Di Laravel Package
nette/di
Nette DI is a fast, flexible dependency injection container for PHP with smart autowiring and compile-time configuration. It helps structure applications cleanly, reduce boilerplate, and catch wiring errors early. Ideal for Nette Framework and standalone PHP projects.
💎 Flexible, compiled and full-featured Dependency Injection Container with perfectly usable autowiring and support for all new PHP 8 features.
Frequently asked questions about Di
- Can I use nette/di with Laravel instead of Laravel's built-in container?
- Not as a drop-in replacement. Illuminate\Container resolves services lazily at request time using reflection, service providers, and facades, while nette/di compiles NEON configuration into plain PHP ahead of time, so the two are not interchangeable. Layering nette/di across the request path leaves you with two singleton scopes and two debugging surfaces. It fits better at the edges, for example an isolated bounded context or SDK package that wants deterministic, reflection-free composition.
- How do I install nette/di with Composer in a Laravel project?
- Run composer require nette/di. The package requires PHP 8.1 or newer and pulls in nette/utils, nette/neon, nette/php-generator, and nette/schema, none of which overlap with Laravel's own dependencies, so co-installation risk is low. There is no Laravel auto-discovery provider, so any wiring into a Laravel app is glue you write and maintain yourself.
- Does nette/di support Laravel 10, 11, and 12?
- At the platform level, yes: nette/di requires PHP 8.1+, which aligns with Laravel 10, 11, and 12. However, there is no first-party Laravel bridge and no official statement of support for specific Laravel majors. If you adopt it, you own the integration tests against future Laravel releases.
- Is there a Laravel service provider or Artisan command for nette/di?
- No. The package ships no service provider, no config-cache integration, and no Artisan commands. Everything on the Laravel side, from exposing the compiled container to wiring it into the HTTP kernel or a queue worker, is a deliverable your team must build, document, and test.
- What is NEON configuration and do I need to learn a new syntax?
- NEON is Nette's human-friendly configuration syntax, similar in spirit to YAML, and it is how services, tags, decorators, and factories are declared. Compilation turns those files into readable, optimized PHP classes. If nobody on the team has used NEON before, budget ramp-up time, because there is no Laravel-style config file or facade layer to fall back on.
- Can I bridge nette/di and Laravel's container through PSR-11?
- Yes, and it works in both directions. Nette\Bridges\DIPsr\PsrContainer exposes the compiled nette/di container to any PSR-11 consumer and reports ambiguity rather than silently guessing, while Laravel's container is also PSR-11-compatible. Keep the bridge as a narrow boundary instead of using it to run two containers across your whole application.
- Is nette/di a good fit for Laravel queue workers, CLI tools, and long-running processes?
- Yes, this is where it fits best: queue workers, dev servers, MCP servers, and standalone binaries, where a precompiled container avoids per-request reflection. You can also verify wiring statically with DependencyChecker and Container::getServiceDescriptors(), which behaves more like a build-time contract than Laravel's runtime container. It is a poor fit for the request path of a typical Laravel app.
- How should I handle nette/di's compiled container cache in production?
- Disable auto-rebuild in production, otherwise every request risks triggering a recompile. Make sure the compiled cache directory is not left stale or shared incorrectly across deploys, or workers will serve outdated containers. The safest pattern is regenerating the container as an explicit deploy step and shipping that artifact.
- What license does nette/di use, and is it safe to ship in a commercial Laravel app?
- The GitHub metadata reports the license as NOASSERTION, so treat it as a hard gate rather than a footnote. Nette components have historically been BSD-3-Clause, but you should get legal confirmation of the actual LICENSE file before adding it to a production application. Once cleared, the dependency surface is small and unlikely to conflict with Laravel packages.
- How unstable is nette/di — does it follow semantic versioning?
- Assume minor versions may break. Versions 3.2.0, 3.2.2, and 3.0.12 all shipped explicit backward-compatibility breaks, covering %parameters% deprecation, generated accessor return types, getServiceType() semantics, and NEON constant resolution. Pin exact versions and review the changelog on every upgrade. Metadata such as the dependents count and last-release date is inconsistent with the project's activity, so verify release cadence directly against the repository.
Weaver
How can I help you explore Laravel packages today?