- Is nette/application a Laravel package?
- No. nette/application is the MVC kernel of the Nette Framework, a component-based presenter and control architecture with its own DI container, router, Latte templating, and Tracy debugger. It ships no Laravel service provider, facade, config stub, or Illuminate contracts. Installing it in a Laravel app is a whole-framework commitment, not a normal Composer dependency.
- Can I use nette/application inside a Laravel application?
- There is effectively no supported path to run nette/application inside a Laravel application. Laravel's HTTP kernel already owns routing, sessions, CSRF, error handling, and the container, and Nette would need to own those too. A bespoke bridge would require request/response translation and container isolation with no upstream support. If the target codebase is Laravel, treat this as a no-go.
- How do I install and bootstrap nette/application?
- Install with composer require nette/application, then bootstrap a front controller such as index.php that creates Nette\Application\Application, a router, and presenter classes. In practice you also add nette/di, nette/routing, latte/latte, and tracy/tracy. Presenters are discovered by ApplicationExtension via scanDirs and the robot loader. This is a Nette bootstrap, not an Artisan package install.
- What PHP version and Laravel version does nette/application support?
- The PHP floor is 8.1+ as of nette/application 3.2.0, and the package is tightly coupled to nette/di, nette/routing, and Latte 3.1. There is no Laravel version support because it is not a Laravel package. Check the composer.json of the exact tag you pin before upgrading.
- Does nette/application provide a service provider, facade, or Laravel config?
- No. There is no Laravel service provider, facade, config stub, or contract against Illuminate classes. Configuration is handled through Nette's DI container, typically NEON config files and ApplicationExtension settings such as scanDirs. Do not expect a config/application.php file or publishable Laravel assets.
- What license does nette/application use?
- The package metadata records the license as NOASSERTION. Nette historically ships under a New BSD or BSD-3-Clause license, but legal should confirm the exact LICENSE text in the pinned release. Until that is cleared, treat licensing as an unresolved blocker for commercial distribution.
- Is nette/application production-ready and maintainable?
- It is mature for Nette-native projects, but it is a single-vendor framework with a smaller maintainer base than Symfony or Laravel. The changelog shows BC breaks at minor boundaries, such as TemplateFactory::createTemplate return type changes, Presenter::getContext errors, and removal of the SECURED flag. Upgrades are a coordinated dance across nette/application, nette/di, nette/routing, Latte, and Tracy. Also verify the release tag and checksum because a future-dated release entry is an anomaly.
- How do I test nette/application presenters?
- Testing is done as normal PHP unit or integration tests around presenter classes, routing, and services, but there is no Laravel testing harness or TestCase integration. You will not get Laravel's HTTP test helpers, facades, or container assertions. Plan to build a Nette-specific test bootstrap and request/response setup.
- What are alternatives to nette/application for Laravel developers?
- For Laravel projects, stay with Laravel's own MVC stack: controllers, routing, Blade or Livewire, and Laravel's container and HTTP kernel. Symfony components are another natural alternative if you want framework-agnostic pieces. Nette Application is not a drop-in alternative inside Laravel; it is a replacement platform.
- When does nette/application fit best?
- It fits best in greenfield PHP 8.1+ applications with no existing framework, or in an existing Nette application. It is strongest when you want component-based presenters, flexible routing, server-rendered Latte templates, and fine-grained AJAX snippet updates. It does not fit Laravel or Symfony full-stack apps where another kernel already owns the request lifecycle.