Inline Field Update Laravel Package

Getting Started

Install the package with Composer and let Laravel's package discovery register the service provider:

composer require vendor/package:^0.3.2

Look first at:

1. The README's "Usage" block — it shows the entry point that returns a rule set (the accessor you will call from a Form Request or a Validator::make() call).
2. The service provider — check for a mergeConfigFrom/publishes pair. If a config file exists, run php artisan vendor:publish --tag=... before writing any rules, otherwise your overrides will be silently ignored.
3. The tests directory — for a pre-1.0 package this is the most reliable specification of behaviour, especially around edge cases like empty rule sets.

Your first use case is almost always the same: resolve a rule set for a model or form and hand it straight to the validator.

$rules = app(RuleProvider::class)->rulesFor(CreateUserRequest::class);

Validator::make($payload, $rules)->validate();

As of v0.3.2 the accessor returns [] rather than throwing or returning null when no rules are defined, so the call above is safe to make unconditionally — you no longer need a null guard before passing the result to the validator.

Implementation Patterns

Form Request delegation. Keep rules() thin and let the package own the rule definitions:

public function rules(): array
{
    return $this->ruleProvider->rulesFor(self::class);
}

This keeps authorization and preparation logic in the request while the package stays the single source of truth for validation shape.

Merging with request-local rules. Use array_merge (or the spread operator) when you need to layer context-specific rules on top:

return array_merge(
    $this->ruleProvider->rulesFor(self::class),
    ['avatar' => ['nullable', 'image', 'max:2048']],
);

Because the accessor is guaranteed to return an array, the merge is always type-safe — no ?? [] fallback required.

Conditional rule sets. Combine the package output with Rule::when() or sometimes for create-vs-update flows rather than duplicating rule sets per verb.

Deriving artifacts. An array-returning rule set is easy to reuse for OpenAPI schema generation, front-end form metadata, or a php artisan rules:dump debugging command. Iterate with foreach — safe now even on empty output.

Testing. Assert on the array contract directly, including the empty case:

$this->assertSame([], $provider->rulesFor(NoRulesRequest::class));

Feature-test the 422 path with assertJsonValidationErrors() so a regression in the package's output shape fails loudly rather than letting payloads through.

Gotchas and Tips

The v0.3.2 change is small but not purely cosmetic. Code written against earlier versions that distinguishes "no rules" from "empty rules" via is_null() or a try/catch will now take the wrong branch. if (! $rules) and count($rules) === 0 continue to behave as before; is_null($rules) and catch-based handling do not. Grep for both patterns when bumping the lock file.

Empty array means "nothing is validated" — not "nothing is allowed." A request whose rule set resolves to [] passes validation for every payload, including an empty one. If a missing rule set is a bug in your application, assert non-emptiness explicitly (a test, or a check in the service provider boot) rather than relying on an exception that no longer fires.

Distinguish the two empty cases. "No rules defined for this class" and "rules defined but all filtered out by conditions" both surface as []. If you need to tell them apart for logging or CI checks, wrap the call in your own resolver that records which branch was taken.

Dot notation and wildcards. Nested keys must be expressed as items.*.sku; a rule set built for a flat array will silently not validate nested payloads. Verify with a deliberately malformed nested payload.

Config caching. If rule definitions are read from config, php artisan config:cache will freeze them at deploy time. Any dynamic rule generation must live outside the config layer or be regenerated as part of the deploy.

Pre-1.0 versioning. Pin to ^0.3.2 and read the changelog on every minor bump — 0.x releases are permitted to change return shapes, and this release is a good example of a behavioural change shipped under a patch number.

Debugging. When validation behaves unexpectedly, dump the resolved array immediately before Validator::make() and inspect ->errors() separately; comparing the rule set to what you expected is far faster than reading validator internals.

Extension points. Custom rules should implement Illuminate\Contracts\Validation\ValidationRule; register project-wide macros in a service provider rather than editing published package config, so upgrades stay clean.