Laravel Validation Rules

Small rules become shared maintenance

Validation code is easy to copy into the next application. The difficulty arrives later, when a correction belongs in several projects and each has its own slightly different version. A short rule can become a maintenance problem simply because nobody has an obvious place to make the shared fix.

I started Laravel Validation Rules in 2017 to give those rules a home. The organisation holds small packages for individual validation concerns, with usage collected on its own website. The decision to publish each rule separately matters as much as the collection itself: an application can take the rule it needs without adopting a complete validation toolkit.

One dependency for one decision

If an application needs to validate a timezone, that requirement should be enough to choose a dependency. It should not also have to take rules for credit cards, phone numbers or offensive content. Keeping the packages separate makes the relationship between the application requirement and the installed package explicit.

It also gives a correction a shared destination. Instead of editing a copied rule in one application and remembering where else it went, a fix can be published in the package used by those applications. They still need to take the relevant update, but the corrected implementation has one place to live. That is the maintenance benefit I wanted from publishing code this small.

The tradeoff is visible in the organisation's structure. There are more repositories to navigate than there would be for a single library. The shared organisation and usage website bring them together for discovery, while installation stays specific to each rule. Finding related work and depending on related work do not have to be the same decision.

Define the question narrowly

The collection includes rules for credit card numbers, phone number formats, UK mobile numbers and two- or three-character country codes. Other packages cover US states and Canadian provinces, timezones, colours and subdomains. There are also rules for public or private IP addresses, offensive content and passwords exposed in a known breach.

Those names describe different decisions, even where the inputs look similar. A general phone format and a UK mobile number are separate requirements. An IP address being public or private is a more specific question than whether it looks like an address. A password appearing in breach data is a particular reason to reject it. Keeping the rules focused lets an application choose the question it actually needs answered.

I want that boundary to remain clear when using the packages too. A phone format check should be read as a format check. A rule concerned with exposed passwords answers the exposure question. The application still owns the wider decision about what it will accept and what other checks belong alongside that rule. A narrow package is useful because its responsibility is understandable, not because one successful validation can stand in for every other requirement.

Enough structure to keep using it

The organisation has fifteen repositories, including its website and organisation material. Ten packages are published on Packagist. The published download total is 3,881,136, with the rules still installed daily. That is a measure of distribution rather than a count of distinct applications, but it gives some scale to work that began with small, reusable pieces of validation code.

The enduring choice is the package boundary. Each application can declare the particular validation dependency it uses, each shared correction has a home and the collection can remain useful without requiring every consumer to need the same set of rules. For code that otherwise tends to disappear into project-specific helpers, that is enough structure to make reuse worth maintaining.