Feature: Native rule to enforce a minimum count of non-whitespace characters

[skpassegna]

Problem

Laravel currently has no built-in validation rule that enforces a minimum number of meaningful (non-whitespace, non-punctuation) characters in a string field. The closest combination a developer would naturally reach for is:

'description' => ['required', 'min:10', 'string'],

This looks like it should guarantee at least 10 real characters of content. It does not.

Reproduction

Given the rules above, the following input passes validation:

"    .   .   .   ."

The pipeline processes it as:

1. TrimStrings middleware strips leading/trailing whitespace → ". . . ."
2. required passes — the value is not null or empty
3. min:10 passes — the trimmed string is 13 characters long
4. string passes — it is a string

The value stored is ". . . ." — content that carries no meaning in any real-world textarea (comment box, description field, message field).

Why this is not a min/max bug

min/max counts raw string length. That is correct and documented behavior. required checks for null/empty. Also correct.

The gap is that no native rule exists to express: "this field must contain at least N characters that are not whitespace or punctuation."

A developer can work around this today with regex or a custom Rule class, but the combination required min/max:N string creates a false sense of security that the common case is covered. It is not.

Proposed rule

A new rule — char:N — that counts only Unicode letter/digit characters (\pL\pN) after stripping everything else:

// Fails: stripped value "......" has 0 letters
'description' => ['required', 'char:4'],

// Passes: "Hello world" has 10 letters
'description' => ['required', 'chat:10'],

Implementation would be straightforward:

$stripped = preg_replace('/[^\pL\pN]/u', '', $value);
return mb_strlen($stripped) >= $this->minimum;

Why this belongs in the framework

This is not a niche use case. Any <textarea> for comments, descriptions, reviews, or messages faces this exact gap. The fix requires framework awareness because the appropriate rule name, error message translation key, and documentation entry all need to exist first-party to be discoverable.

I apologize for any English error in my text.

[shaedrich]

Would you only add this or a group of rules (similar to password policies):

'description' => ['required', 'chars:4', 'punct:1', 'nums:3'],
// or
'description' => ['required', Rule::ctype()->chars(4)->punct(1)->nums(3)],

[skpassegna]

Fair point .

I would suggest starting with chars:N as a primitive rule (the way min, max, digits are primitives), and later composing them under a fluent builder if there is appetite for it. That keeps the initial PR small and the scope clear.

A composable Rule::text() (or Rule::ctype()) following the same pattern would be the ideal long-term design:

'description' => ['required', Rule::text()->chars(4)->digits(1)],
'comment'     => ['required', Rule::text()->chars(10)],
'code'        => ['required', Rule::text()->nums(3)->chars(2)],

This would be more expressive, more discoverable, and consistent with existing fluent rule builders in the framework.

My original proposal (chars:N as a standalone rule) is the minimal viable version — covering the most common case with the least friction to implement and review. But if the team is open to a fuller surface, the fluent approach is clearly the right shape for it.

Either way, the core need is the same: a first-party way to say "this field must contain at least N letters or digits".

[shaedrich]

digits:3 does already exist. Of course not as part of the new class-based rule but if you want to have both a string rule and a class-based one, I'd suggest keeping naming consistent

[skpassegna]

Following the existing min_{rule} pattern where {rule} is already a named rule in the framework:

Existing rule	Exact count	Min count
digits:N	exactly N digits	min_digits:N exists
alpha	100% letters only	min_alpha:N (proposed)
alpha_num	100% letters + digits	min_alpha_num:N (extension)

min_alpha:N is the most consistent naming — alpha already exists,
min_ already exists as a prefix on a type rule, the combination is a direct parallel with no new vocabulary introduced.

The ascii modifier would also carry over naturally:

'description' => ['required', 'min_alpha:10'], 
'slug'        => ['required', 'min_alpha:4,ascii'],

I just went to scroll a bit more the docs, and think that adding new rule may be unnecessary.

Thanks

[shaedrich]

Yeah, this makes sense 👍🏻