- What does nwidart/laravel-normalizer do?
- It is a lightweight Laravel package for standardizing data so the rest of your application sees consistent values. You define configurable normalizers that transform incoming input, model attributes, or API payloads—trimming, casing, and casting—instead of scattering that logic across controllers and models. It is intended as a thin layer at the edges of your app, before validation, persistence, or domain logic.
- How do I install nwidart/laravel-normalizer with Composer?
- Run composer require nwidart/laravel-normalizer and register the package service provider and configuration as shown in the repository. Do not assume installation succeeds: the package is at 0.2.x with a 2016 release, so its PHP and illuminate/* constraints may not resolve on a current Laravel host. Test a clean composer require first, and treat any need for --ignore-platform-reqs or hand-edited constraints as a decision point rather than a workaround.
- Does nwidart/laravel-normalizer support Laravel 10, 11, or PHP 8?
- By default, no. The last release is 2016-07-27 at version 0.2.x, when the constraints were written for PHP 7.0 and Laravel 5.x, so expect resolution failures on PHP 8.1+ and Laravel 9/10/11. Even if you force installation, scalar type hints and removed Laravel helpers can cause runtime TypeErrors on paths you exercise. Treat it as not fit-for-purpose on modern stacks unless you fork and maintain it.
- Is nwidart/laravel-normalizer maintained and safe for production?
- It is effectively unmaintained: pre-1.0, roughly 12 stars, no visible CI matrix, no security-response posture, and no deprecation policy. A dormant dependency is a standing finding in dependency and security audits and requires a documented exception or a vendoring decision. If you adopt it, scope it to non-critical, internal data shaping—not compliance, billing, or customer-facing contracts—and assign a named owner.
- How do I configure normalizers in nwidart/laravel-normalizer?
- Configuration is framework-native: normalizers are registered through Laravel's service container and config, so you define reusable transformations in configuration and resolve them where needed. The package is old and documentation is sparse, so confirm the exact config key and whether a publishable config file exists in the repository before wiring it into your app. Keep configuration explicit and covered by tests, since there is no upstream stability promise at 0.x.
- Can I normalize request input before validation in Laravel with this package?
- Yes—the package is designed for request integration, so you can normalize incoming payloads at the edge before validation runs. That gives validators and downstream code predictable values instead of scattered trim and casing calls. On modern Laravel, compare this with FormRequest::prepareForValidation, which provides the same pre-validation hook with first-party support and no orphan dependency.
- How do I apply multiple normalization rules in sequence?
- Use the chainable pipeline: define individual normalizers and apply them in order so each rule receives the output of the previous one. Order matters—normalize whitespace before casing, for example—so write tests that assert the final shape rather than intermediate steps. Because the package is 0.x, pin the version and verify chaining behavior under your PHP version before relying on it.
- Can nwidart/laravel-normalizer normalize model attributes?
- Yes, the package advertises model integration so attributes can be normalized consistently before persistence or domain logic. That can reduce duplicated mutator and casting logic across models. Weigh it against Laravel's built-in casts and mutators, which are first-party and maintained; if you adopt the package, keep model normalization out of critical write paths until you have tested the lifecycle behavior yourself.
- How do I add a custom normalizer and test it?
- Implement the package's normalizer contract and register your class through the container or config, then cover it with unit tests that assert input-to-output behavior, including edge cases like nulls and empty strings. Check whether scalar type hints appear on public methods or interfaces you implement, because on PHP 8 those become runtime TypeErrors rather than install-time warnings. Since upstream has no visible CI matrix, that test burden is yours.
- What are the alternatives to nwidart/laravel-normalizer, and should I fork it or build in-house?
- The first-party alternatives are FormRequest::prepareForValidation, Arr:: helpers, validation rules, casts, mutators, and a DTO or hydrator layer—all maintained with Laravel itself. The package's scope is small, so a bounded in-house normalizer layer with a few owned classes and tests usually costs less than adopting or forking a nine-year-stale 0.2.x dependency. Fork only if you have a legacy Laravel 5.x / PHP 7.0 app with real duplicated normalization logic, and document a named owner and exit path.