Utils Laravel Package

Product Decisions This Supports

• Build vs. buy for commodity utilities. Decide whether to keep hand-rolling string, array, validation, and filesystem helpers or adopt a small, battle-tested library. High-value replacements include Strings::webalize() for Unicode-aware slugs, Validators for emails/URLs/identifiers, FileSystem::isValidFilename() for upload safety, and Json for consistent encode/decode error handling.
• Feature delivery acceleration. Shortens implementation of content features (slugs, truncation, sanitization, case conversion), admin/upload features (image type detection, simple resizing, avatar handling), import/export (safe JSON reading and decoding), and integration workflows.
• Security roadmap decisions. Replacing ad-hoc exec()/shell_exec() calls with Process::runExecutable() (argument arrays, no shell) reduces injection risk. Centralized filename validation reduces path traversal, control-character, and Windows reserved-name issues.
• Make-vs-integrate for image handling. Image covers lightweight GD-based resizing, type detection, and basic drawing. The decision is whether that is sufficient versus adopting Intervention Image, Glide, or a hosted image service for advanced transformations, caching, and format coverage.
• Dependency policy and PHP upgrade planning. Whether to permit framework-agnostic micro-dependencies alongside Laravel and Symfony components. This affects PHP version floor (the v4.1 line we are evaluating requires PHP 8.2), upgrade cadence, and long-term maintenance surface. The 4.0 branch now declares support for PHP 8.0 through 8.6 (v4.0.11 adds PHP 8.6), which is a useful signal for teams sequencing future PHP upgrades — but confirm the floor/target for the specific branch you pin, since 4.0 and 4.1 differ.
• Maintenance ROI and risk reduction. Fewer bespoke helpers means fewer custom edge cases to test and own — Unicode behavior, DST-aware date parsing, float comparison, JSON depth/error handling, and cross-platform process behavior. Forward compatibility with upcoming PHP releases (8.6) lowers the cost of the next runtime upgrade.

When to Consider This Package

Adopt when:

• You are on PHP 8.2+ (for the v4.1 line) and need a small, low-coupling utility layer that does not pull in a framework. If you are pinned to an older runtime, the 4.0 branch advertises PHP 8.0–8.6 support, but treat that as a separate pin/upgrade path and verify it against your Laravel and Symfony constraints.
• You have concrete gaps not well covered by Laravel: Unicode transliteration/slugging (Strings::webalize() requires intl), strict/safe JSON decoding, cross-platform filename validation, image type detection and simple GD operations, iterable helpers (Iterables::memoize(), mapWithKeys()), and float comparison (Floats).
• You need controlled subprocess execution — timeouts, incremental stdout/stderr consumption, exit-code checks, Windows support — and prefer a compact API.
• You are doing security or compliance hardening where vetted helpers reduce custom code for filename/path sanitization and JSON parsing.
• You are building internal tools, CLI jobs, or shared packages that must work in both Laravel and non-Laravel PHP codebases.
• You value documented releases, PHPStan-enforced CI, active maintenance, and forward runtime compatibility (PHP 8.6 support landed in v4.0.11) as adoption signals — this matters if your platform roadmap has a PHP upgrade inside the next 12–18 months.

Look elsewhere when:

• The capability already exists adequately in Laravel or Symfony — Str, Arr, Validator, Symfony Process, Flysystem/File, and Laravel’s JSON response handling. Adding nette/utils for overlapping functions increases dependency surface with limited product benefit.
• You need advanced image pipelines: crops, filters, format conversion at scale, CDN integration, or responsive derivatives. Use Intervention Image, Glide, or a managed service.
• Licensing is unresolved. GitHub still reports NOASSERTION; block production adoption until legal confirms the actual license terms.
• You are below the supported PHP floor for your pinned branch and cannot upgrade, or you require LTS-style guarantees beyond the project’s release cadence. Note that a patch-level PHP 8.6 compatibility statement is not an LTS commitment.
• You need framework-integrated behavior (queues, Laravel validation messages, config, DI, localized error responses). Prefer native Laravel components.
• You want a single dependency covering many concerns. This is a utility grab-bag; piecemeal adoption means unused surface and unclear ownership.

How to Pitch It (Stakeholders)

For executives: nette/utils is a small, mature, framework-agnostic PHP utility library that helps us ship common features faster — slug generation, safe file uploads, JSON parsing, lightweight image handling, and controlled subprocess execution — with less custom code and fewer security edge cases. It is low-risk to evaluate: no framework lock-in, active releases (most recently v4.1.4, with the 4.0 branch adding PHP 8.6 support), documented changes, and static analysis in CI. The main adoption considerations are the PHP 8.2 floor for v4.1 and license confirmation, since GitHub reports NOASSERTION. Recommended approach: time-boxed pilot in one service, measure delivery speed and defect reduction, then standardize only where it replaces custom code — not where Laravel already provides equivalent functionality.

For engineering: treat this as a targeted utility layer, not a framework replacement. Highest-value adoptions are Strings (Unicode and slugging), Validators, Json (strict decoding), FileSystem::isValidFilename(), Image for simple GD tasks, and selected Iterables/Floats helpers. Avoid duplicating Laravel/Symfony capabilities — especially Symfony Process, Str, and Arr — unless there is a clear behavioral win. Pin versions and the minor branch explicitly (4.0 vs 4.1 have different PHP floors; 4.0.11 adds PHP 8.6 support, which is a compatibility signal, not a feature change), require the correct PHP minimum, run PHPStan, and wrap third-party calls behind small internal adapters so we can swap implementations later. Watch for breaking changes across majors: v4 changed DateTime strictness and requires intl for webalize(). Confirm license terms before production use.