On a manually built Laravel validator, what do the after(), sometimes() and stopOnFirstFailure() methods add, and when does each take effect?

## Three configuration methods `Validator::make()` returns an unevaluated `Illuminate\Validation\Validator`. Before you call `fails()`, `passes()` or `validate()`, three methods let you adjust how it will run. ## after(): checks that span fields or need a query ```php $validator->after(function (Validator $validator) use ($row) { if ($row['sale_price'] > $row['price']) { $validator->errors()->add('sale_price', 'Sale price cannot exceed price.'); } }); ``` - Accepts a closure, an invokable object, or an **array** of them (each receives the validator). - Callbacks run **after all rules**, whether or not the rules passed — so guard against missing or malformed values, for example by returning early when `$validator->errors()->isNotEmpty()`. - Adding an error in a callback makes `fails()` return `true`. ## sometimes(): conditional rules on a manual validator ```php $validator->sometimes('discount_reason', ['required', 'max:200'], function (Fluent $input) { return $input->discount > 30; }); ``` - First argument: one field or an array of fields. - Second: rules to add when the condition holds. - Third: a callback receiving the data as `Illuminate\Support\Fluent`. For a wildcard field like `lines.*.reason`, it also receives the **current item** as a second argument, so each element can be judged on its own values. Two things are easy to miss: 1. The callback runs **when you call `sometimes()`**, against the data given to `make()`. If you change the data later (with `setData()`), the decision is not re-evaluated. 2. The method and the `sometimes` **rule** share a name but not a meaning: the rule means "only validate when the key is present"; the method means "add these rules when this closure says so". ## stopOnFirstFailure(): stop at the first bad field ```php if ($validator->stopOnFirstFailure()->fails()) { /* ... */ } ``` - Before moving to the next field, the validator checks whether any error exists and stops if so. - `after()` callbacks still run afterwards. - It differs from the `bail` rule, which stops the remaining rules **of one field**. Use it when you only need to know that the data is bad — for example rejecting a CSV row quickly — and the full list of problems is not shown to anyone. ## Timing summary | Method | When its logic runs | Effect | |---|---|---| | `after($cb)` | during `passes()`, after all rules | callbacks may add errors | | `sometimes($f, $r, $cb)` | immediately, at the call | adds rules to the validator if `$cb` is true | | `stopOnFirstFailure()` | during `passes()` | stops iterating fields after the first error | ## Putting them together for an import row 1. `Validator::make($row, $baseRules)` 2. `->sometimes('discount_reason', 'required', fn ($in) => $in->discount > 30)` 3. `->after(fn ($v) => $this->checkCategory($v, $row))` 4. `->stopOnFirstFailure()` 5. `->fails()` — one boolean per row, with at most one field reported. ## Versus other places for the same logic - In a form request, the equivalents are its `after()` method and its stop-on-first-failure setting; that is where they belong when validating a request. - `Rule::when()` inside the rules array can often replace `sometimes()` and keeps the condition next to the field; `sometimes()` is handy when you add conditions after construction or across several fields at once. ## Pitfalls - Calling `sometimes()` after `fails()` has no effect on the result already computed; configure first. - Expecting `stopOnFirstFailure()` to skip `after()` callbacks — they still run. - Returning a boolean from an `after` callback expecting it to fail validation; only added errors count. ## How to explain the difference quickly `sometimes()` decides **which rules exist**, at the moment you call it. `after()` adds **extra checks** after the rules run. `stopOnFirstFailure()` decides **how far** the rule loop goes. Keeping those three verbs apart — which, extra, how far — is usually enough to answer the follow-ups.