Nullify Laravel Package

Product Decisions This Supports

• Data-quality standard: define "empty" once. The package gives the team a single, testable definition of emptiness (empty strings, whitespace, empty arrays, nested structures) that every ingestion path can share instead of each developer re-implementing if ($value === '').
• Database semantics: NULL vs ''. Choosing to persist "no value" as NULL rather than empty string is a schema-level product decision. It affects whereNull() filtering, unique indexes, aggregate/COUNT behavior, and how reporting tools interpret missing data. This package makes that decision cheap to enforce at the boundaries.
• Input normalization at the edge. Useful in form-request/prepareForValidation, API middleware, CSV/import pipelines, and webhook handlers so downstream domain logic never has to distinguish "absent" from "blank."
• Reducing a recurring bug class. Most of the value is defensive: fewer null vs '' mismatches in conditionals, fewer failed unique constraints, cleaner JSON output contracts.
• Build vs. buy (really: build vs. adopt). This is a ~20-line concern. The decision is not "is this hard?" but "do we want a versioned, tested dependency or a house helper we own?" At 16 stars and zero dependents, treat it as a reference implementation / vendorable snippet more than a strategic dependency.
• Not a roadmap item. This is infrastructure hygiene, not a user-facing capability. Fund it as part of a data-consistency cleanup, not as a feature bet.

When to Consider This Package

Adopt when:

• You have multiple input sources (forms, APIs, imports, third-party webhooks) producing inconsistent blanks and you're seeing real defects from '' vs null ambiguity.
• You've committed to NULL as the canonical "missing" representation in the database and want enforcement at ingestion rather than scattered per-controller checks.
• You need recursive normalization of nested payloads, where a hand-rolled one-liner starts to sprawl.
• You want the behavior covered by tests without writing and maintaining them yourself.

Look elsewhere (or write a local helper) when:

• Your "emptiness" rules are business-specific — e.g., '0', 'false', 'N/A', '-', or placeholder sentinels must be treated as null. Generic packages rarely match domain semantics, and silently nulling '0' is a genuine data-loss risk worth verifying explicitly.
• You need type coercion or casting, not just nulling — reach for a DTO/hydrator or Laravel casts instead.
• The need is confined to one endpoint — prepareForValidation() is already in the framework.
• Dependency policy is strict (security review cost, supply-chain posture) and a 20-line internal utility is cheaper than onboarding a low-traffic third-party package.
• Maintenance risk is unacceptable: single maintainer, 0 dependents, last release March 2024. If it's load-bearing, vendor/fork it with a test suite rather than pinning the dependency.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed utility that standardizes how we store "no value" in our database. The business payoff is downstream: cleaner data for reporting and analytics, fewer intermittent bugs from blank-vs-missing confusion, and more predictable API contracts. Cost is near zero; risk is low but non-zero because it's a low-adoption package — so we'd adopt it as a thin, forkable utility rather than a strategic dependency.

To engineering: Adopt michael-rubel/nullify (or lift its logic into app/Support) to normalize empty input to null at our system boundaries — form requests, API middleware, and import handlers. It removes a recurring class of '' vs null defects and lets queries rely on whereNull(). Two conditions before we merge: (1) confirm and test our definition of "empty" — especially whether '0' and whitespace should be nulled, since generic behavior may not match our domain; (2) wrap it behind our own helper so we can swap or extend it without touching call sites. Given the package's size and adoption profile, treat it as a vetted snippet with tests, not an unexamined dependency.