The badge says New BSD and the repository field says nothing

Two different statements about the terms

The header carries a badge naming the New BSD terms and links it to a file in the repository root, which is a precise and verifiable claim. The repository metadata on the hosting side classifies the same project differently, as custom terms that cannot be categorized automatically. Both can be true at once, since a classifier reading a repository field finds nothing standard there while the badge and the file state the answer, but they produce different behavior in a compliance pipeline: a scanner will either flag the project as unclassifiable or will skip it, and a human reading the badge will conclude the answer without opening the file. That file is named license.md rather than LICENSE, a naming difference some automated tooling also looks for. If this repository enters an approval process, the thing to check is the file, not the badge.

Seventeen classes, one documentation page each

The introduction is a list of seventeen entries and each one is a link to its own page on doc.nette.org, which tells you the shape of the package: it is not one utility function but seventeen small class groups, each solving one problem. Arrays and Iterables cover collection work, Strings covers text functions, and Callback covers PHP callbacks. Filesystem covers copying and renaming while Finder covers locating files and directories. Floats exists as its own entry for floating point numbers, and Type covers PHP data types. Then there are the ones with a specific job: Images for cropping, resizing and rotating, HTML elements for generating markup, JSON for encoding and decoding, Validation for checking inputs, Generating Random Strings for slugs and strong passwords, and Paginator for pagination math. PHP Reflection wraps reflection, Helper Functions collects the procedural helpers, and SmartObject is described as PHP object enhancements.

SmartObject on the list of a PHP 8 package

One entry is worth pausing on. SmartObject is described as PHP object enhancements, and it is listed in a package whose stated compatibility is PHP 8.2 to 8.5. The name belongs to a pattern that was associated with the PHP 5 era, when a base class gave property access, notification of changes and a shorthand for getters. In a package that already requires a modern runtime, keeping such an entry is either compatibility for code written against the older pattern or a deliberate statement that the concept still has a place. The README does not say which, and the class's own documentation page is where that would be answered. It is also the one name in the list that a reader arriving from another ecosystem will not recognize, so it is the one to look up first.

Composer, and one line about PHP versions

Installation is documented in one sentence and one command:

composer require nette/utils

The recommended way is Composer, and the compatibility statement is that Nette Utils 4.1 is compatible with PHP 8.2 to 8.5. That floor is the number worth checking first, since the package is designed to be depended on by everything else in a project. The README is otherwise short: there is no usage example, no quick start, no configuration section, because each of the seventeen entries has a documentation page that carries its own examples. That structure is a deliberate division. The front page tells you whether the package covers the problem you have, and the documentation site tells you how to use the specific class. A support request links to GitHub Sponsors and a buy me a coffee badge addressed to the maintainer, which is also how Nette funds the rest of its libraries.

The quality tooling lives in the repository root

The top-level entries describe how the package is checked rather than what it does. There is ncs.xml, which is the Nette Coding Standard configuration, so the project enforces its own house style on itself. There is phpstan.neon, so static analysis is configured in the repository rather than left to consumers, and .phpstorm.meta.php, which is a metadata file telling PhpStorm about the types the package exposes so an editor can complete them without extra configuration in each consuming project. Then there are tests/ with a workflow badge and a coveralls badge, and AGENTS.md, which is a file written for coding agents working in the repository. None of that is user-facing, and all of it is the difference between a package whose behavior you can predict and one whose behavior you learn by trial. The docs/ directory holds the documentation sources that publish to the site the README links to, Commits to master continued through 2026-08-18.

Where the utilities overlap with what you already have

The risk with a utility package is overlap rather than absence. Every framework bundles some version of these: validation, image handling, HTML escaping, JSON helpers and string utilities are common enough that a Symfony, Laravel or Nette application already has them. Adopting nette/utils into such a project means choosing one implementation over another for each function, and the choice is invisible at the call site because the names are generic. That is the case to weigh first. The case where it wins is a plain PHP project with no framework, or one migrating away from one, where the seventeen classes are a coherent set with one maintainer and one version cadence rather than a scatter of packages. A narrower second case is taking two or three classes from it because they are well tested, without adopting the rest, which is a legitimate use of a utility package even when the framework already covers the other fourteen.

Where nette/utils is the wrong choice

Four cases. The first is a project on an older PHP than the stated 8.2 floor, since the current line is 4.1. The second is a project that already has a framework with its own helpers, where adding this package creates two implementations of the same utility and a decision about which to import at each call site. The third is a team that expects a general-purpose standard library. Seventeen classes is a focused set rather than a foundation, and the topics attached to the repository reflect that: array manipulations, JSON, pagination, validation, strings, filesystem, utilities. There is no HTTP client, no database layer, no date library. The fourth is anyone evaluating it for security properties. The repository carries static analysis and coding standard configuration, which is a quality signal about style rather than a claim about behavior, and the specific functions worth auditing are the ones that generate or check values, such as random string generation and validation, rather than the whole package.

Editorial conclusion

nette/utils suits a plain PHP project, or one migrating away from a framework, that wants a vetted utility layer covering validation, images, JSON and strings. It does not suit a Symfony or Laravel application that already bundles those helpers, since two implementations would sit side by side at every call site. Before adopting, install with composer require nette/utils, check your runtime against the stated 8.2 to 8.5 range, and open the file at the repository root rather than trusting the badge when the terms matter to your process.

Frequently asked questions

Official sources

1. Issues
2. nette/utils on GitHub
3. Project website
4. README
5. Releases