Laravel Nullable Fields Laravel Package

Product Decisions This Supports

• Build vs. buy on data-hygiene plumbing. This is a "buy" decision only in the loosest sense — it's a ~30-line Eloquent trait with a single job: before a model is saved, any attribute declared in $nullable that is empty ('', empty array) is persisted as NULL instead of an empty string. The decision it really supports is where normalization lives in your architecture: at the persistence boundary (this package), at the HTTP boundary (Laravel's ConvertEmptyStringsToNull middleware), or scattered across form requests and services.
• Feature scoping for "optional" fields. Any roadmap item that adds a nullable string field — secondary email, VAT/tax ID, middle name, coupon code, external reference, optional slug — inherits a class of bug: '' is not NULL. The package makes "optional" mean one thing in the database, which lets you stop defending against both states in queries, exports, and API serializers.
• A concrete, high-visibility bug class: unique indexes on optional columns. MySQL and SQL Server permit many NULLs in a unique index but only one ''. Without normalization, the second user who leaves "secondary email" or "tax ID" blank gets a duplicate-key error in production. That's a support-ticket and trust cost, not an architecture cost — and it's the strongest business case for a five-minute change.
• Reporting and segmentation integrity. WHERE col IS NULL and WHERE col = '' return different populations. Picking one convention (null) makes analytics filters, admin search, and null-coalescing logic in views predictable, and makes JSON responses consistent (null rather than "") for downstream consumers.
• Cross-database portability. Oracle already coerces '' to NULL while PostgreSQL and MySQL do not. Normalizing in the model keeps behavior identical when a product line migrates engines.
• Not a differentiating decision. Treat it as an internal engineering-quality choice, not a strategic bet. It should not consume roadmap capacity, procurement cycles, or an ADR longer than a paragraph.

When to Consider This Package

Adopt when most of the following hold:

• You're on a supported Laravel version with Eloquent models that accept writes from multiple entry points — admin forms, public APIs, queue jobs, CSV imports, seeders, third-party webhooks.
• Laravel's global ConvertEmptyStringsToNull middleware is insufficient: it only covers HTTP requests, only applies globally (so you can't preserve '' as meaningful for specific fields), and is frequently disabled or bypassed in tests, jobs, and console commands.
• You have a small, well-understood set of nullable string columns, ideally with unique indexes, where '' vs NULL has already caused a defect or a data-cleanup script.
• You want the convention expressed declaratively on the model rather than as a saving hook copy-pasted into a base class, and you value the readable $nullable list as documentation.
• You're comfortable with the dependency profile: MIT, no transitive dependencies, tiny surface area, one maintainer, 102 stars, zero dependents, last release 2026-03-20. Low social proof, but the blast radius of failure is near zero and the code is forkable in an afternoon.

Look elsewhere, or build in-house, when:

• All writes flow through HTTP and you can simply enable ConvertEmptyStringsToNull. That's one line of framework config versus one dependency.
• You need normalization beyond empty→null — trimming, casing, format validation, phone/EIN canonicalization. Reach for attribute casts, a value-object package, or a dedicated normalizer; don't stack several micro-packages.
• You write via the query builder. Model::where(...)->update() and bulk insert() bypass model events entirely, so the trait silently won't apply. If bulk paths are common, enforce the invariant with a database-level default or a CHECK/trigger strategy plus application-level normalization.
• You need a support commitment. No SLA, no commercial backing, single maintainer. Acceptable here because the package is trivially replaceable; not acceptable if your team's policy forbids micro-dependencies entirely.
• You already have a base model. If your codebase has a shared BaseModel, adding a 20-line saving hook is cheaper than the governance overhead of a new dependency — and it's a legitimate answer.

How to Pitch It (Stakeholders)

For executives — one paragraph: We're evaluating a small, free, MIT-licensed Laravel add-on that fixes an inconsistency in how we store blank optional fields. Today a form submitted empty may be saved as an empty string in some code paths and as a true blank in others, which has produced duplicate-record errors on optional unique fields and mismatched numbers in reporting. The package makes the behavior uniform with a one-line declaration per model. Cost is effectively zero, risk is negligible because the code is a few dozen lines and can be maintained in-house if the author ever stops, and the payoff is fewer data-integrity tickets and cleaner analytics. Recommendation: adopt as a low-ceremony engineering standard, scoped to models with genuinely optional fields.

For engineering — the short version: dyrynda/laravel-nullable-fields gives you a Nullable trait and a protected $nullable = [...] array; on saving, empty values in that list become NULL. It complements — not replaces — ConvertEmptyStringsToNull, which only covers HTTP and applies globally. Use it where optional unique columns or mixed write paths (jobs, imports, APIs) make '' vs NULL ambiguous. Caveats: model events don't fire on query-builder bulk writes, so keep those paths normalized separately; pin the version and add one regression test asserting round-trip null behavior on a model with a unique nullable column; and timebox the evaluation to under an hour. If we'd rather not carry the dependency, the fallback is a saving hook in our base model — functionally equivalent, marginally more code we own.