- What is nette/utils used for in a Laravel application?
- nette/utils is a standalone PHP utility library for string and array manipulation, JSON encoding and decoding, file system checks, image handling, validation, slug generation, password generation, callbacks, reflection, and process execution. In a Laravel app it can fill specific gaps around safe external process execution, strict JSON handling, and file name validation. It is not a Laravel framework package and does not provide service providers or container bindings. You use its static classes directly where needed.
- How do I install nette/utils in Laravel?
- Install it with composer require nette/utils:^4.1; Composer autoloads the classes via PSR-4 and there is no service provider to register. Version 4.1 requires PHP 8.2 or newer, so confirm your Laravel runtime matches before adoption. Verify any optional extensions needed by the modules you plan to use, such as ext-intl, ext-gd, mbstring or iconv, and proc_open.
- Is nette/utils compatible with Laravel 10, 11, and 12?
- It is compatible with Laravel 10 through 12 on PHP 8.2+ because it is framework-agnostic and has minimal dependencies. It is stateless and static, so it is safe in traditional requests, Octane workers, queue workers, and CLI commands. Laravel integration is limited to Composer autoloading; there are no Laravel-specific bindings to configure.
- Should I use nette/utils instead of Laravel's Str and Arr helpers?
- Not by default. nette/utils deliberately overlaps with Illuminate\Support Str and Arr, Laravel's Validator, Illuminate\Process, and the File facade, so adopting it without a standard can create two utility conventions in one codebase. The strongest reason to add it is a specific gap such as no-shell process execution, FileSystem::isValidFilename(), or strict Json behavior. Define when to use nette/utils versus Illuminate equivalents before rolling it out.
- Does nette/utils work with Laravel Octane and queue workers?
- Yes, the library is stateless and uses static utility classes, so there is no shared mutable state to leak between requests or jobs. That makes it safe under Octane, queue workers, and CLI commands. The main caution is not runtime state but testability, because static calls are harder to fake.
- How do I test code that uses nette/utils static classes?
- Strings, FileSystem, Json, and Process are static classes, so unit tests cannot substitute them directly. Code that calls them becomes harder to isolate, and adapters or wrapper services are needed wherever behavior must be faked. If testability of process execution matters, commit to an adapter boundary up front rather than calling Process statically throughout the app.
- What PHP extensions does nette/utils require in production?
- The core library has minimal dependencies, but optional modules need specific extensions. In 4.1.0, Strings::webalize() requires ext-intl, Image requires ext-gd, string length and transliteration fallbacks may use mbstring or iconv, and Process needs proc_open available. Verify and pin these extensions in production, staging, and CI container images before committing to those modules.
- Is nette/utils safe for running external processes?
- The Process API is a strong differentiator because Process::runExecutable() passes arguments as an array without involving a shell, which eliminates shell-injection risk by construction. It also supports timeouts, incremental output consumption, and exit-code checks across Windows and POSIX. You should still review call sites and migrate any shell_exec or exec usage carefully if the security model requires the no-shell path.
- What are the licensing concerns with nette/utils?
- GitHub reports the license as NOASSERTION, and the library is understood to be BSD-family but the metadata does not confirm it. This is a hard gate for production use and requires legal review before adoption. Confirm the approved license set for production dependencies rather than relying on ecosystem assumptions.
- How stable is nette/utils, and how should I pin it?
- Major-version churn is a real concern: the v3 to v4 line removed several Reflection methods, made DateTime strict with an explicit BC break, PascalCased constants, and rewrote Finder. Pin to ^4.1 and gate minor bumps through changelog review, especially for DateTime and Json behavior. Also verify current release and ecosystem data against Packagist because the provided dependents and last release fields are unreliable.