Php Validator Laravel Package

Getting Started

fangstar/php-validator is a small, framework-agnostic PHP parameter-validation component. It predates Laravel's standalone illuminate/validation split being widely used outside Laravel, so the fastest path is to treat it as a single-purpose library rather than a framework component.

1. Install and pin. There has been no release since 2016-11-23, so install with an explicit constraint and commit the lock file:

   composer require fangstar/php-validator:^1.0
   

2. Check the PHP constraint before anything else. Open vendor/fangstar/php-validator/composer.json and confirm the php requirement. A 2016-era package will typically declare >=5.4 or >=5.6; that is a lower bound only, so it will happily install on PHP 8 and then fail at runtime on removed syntax. Run your test suite on your actual target PHP version before adopting.
3. Read src/ first, not the README. The README is Chinese-only and the public API surface is small (one validator class plus a rules file). Ten minutes in src/ will tell you more than the docs: look for the entry-point class, the rule registry/array, and how error messages are stored.
4. First use case — validate a request payload before it reaches your service layer. The conventional shape for packages in this family is a pipe-delimited rule string:

   $validator = new Validator();
   $ok = $validator->check($_POST, [
       'name'  => 'required|max:20',
       'email' => 'required|email',
       'age'   => 'integer|min:18',
   ]);
   

   Verify the exact entry-point name (check, make, validate, or a static call) in src/ — this is the one thing worth confirming by hand before writing anything else.

If you are already on Laravel, stop here and use the framework's Validator instead; this package buys you nothing and costs you a PHP 8 compatibility audit.

Implementation Patterns

Centralize rule sets, don't inline them. The main day-to-day win is having one declarative place per endpoint describing its contract. Put rule arrays in dedicated classes or a config/validation.php map keyed by action name, and have controllers/service methods look them up:

$rules = require __DIR__ . '/../config/validation.php';
$validator->check($payload, $rules['user.create']);

Separate "shape" validation from "business" validation. Use the package to assert types, presence, length, and format; keep uniqueness checks, ownership checks, and state-machine rules in your service layer. Validation libraries of this vintage have no notion of a database context, and bolting one in via custom rules makes failures hard to attribute.

Wrap it once. Because the library is unmaintained, do not let it leak across the codebase. Write a thin adapter — App\Validation\Validator — that exposes validate(array $data, array $rules): array and throws a single ValidationException carrying all messages. That adapter is your escape hatch: when you eventually swap in illuminate/validation or symfony/validator, you change one file.

Error handling. Collect all failures rather than short-circuiting per field; API clients want the full list. Check whether the package stores messages as a flat array or keyed by field — if keyed, array_merge(...array_values($errors)) before returning, and flatten nested/array-field keys yourself.

Custom rules. Every validator in this family has an extension point (a register/extend method or a rules array you can append to). Register custom rules once at bootstrap, not per call, and keep them pure functions of ($value, $param) so they stay testable.

Framework integration. In Slim, Symfony, or a plain front controller, invoke the adapter in middleware so controllers receive only validated input. In Laravel, use a service provider to bind the adapter only if you have a legacy codebase already emitting these rule strings — otherwise migrate them to Laravel rule syntax, which is a near-mechanical translation for the common rules.

Gotchas and Tips

• Abandonment is the headline risk. Zero dependents and no release in ~9 years means no security patches and no PHP 8 fixes. Common breakages in packages of this age: each(), create_function(), curly-brace string offsets ($str{0}), and dynamic-property deprecations. If you adopt it, fork it, tag your fork, and point Composer at your VCS. Do not depend on Packagist staying reachable for a package nobody maintains.
• Loose comparison is the classic trap. Chinese-ecosystem validators of this era frequently use == and empty() internally. Consequences: "0" is treated as empty for required, and 0 == "" is true in PHP 7 but not PHP 8 — so a rule that "worked" in your dev container can change behavior across runtimes. Write a test per rule with falsy inputs: 0, "0", "", null, [], false.
• Validation is not sanitization. Never treat a passing rule set as making input safe for SQL, HTML, or shell contexts. Keep escaping at the sink. This package has no filtering/XSS layer, despite what "参数校验" sometimes implies to readers.
• Watch trailing/leading whitespace and multibyte lengths. If max uses strlen, a 20-character Chinese name fails a max:20 rule. Patch to mb_strlen in your fork and note it in the README diff.
• Debugging failures. If a rule silently never fires, the usual cause is a rule name in your string that doesn't match the registry key — validators in this style skip unknown rules rather than erroring. Add a startup assertion that every rule name in your config exists in the registry; that one check eliminates most "why didn't it validate" tickets.
• Nested and array fields are the weak spot. Validate items.*.price-style paths only if the package explicitly documents wildcard support. If not, loop over the array yourself and validate each element, prefixing error keys with the index.
• Extension points to prefer. If the package exposes a rule registry as a plain array property, treat that as semi-public API and extend via a single bootstrap file. Avoid subclassing the validator — internal method signatures in unmaintained packages are not stable, and a subclass will silently break when you eventually vendor-patch.
• Have the exit plan written down. Given the score profile (high "opportunity" but near-zero adoption and a decade of dormancy), the realistic play is: adopt only for a legacy codebase that already uses it, wrap it behind your own interface, and budget the migration to illuminate/validation as tech debt rather than an open question.