Weave Code
Type Laravel Package
php-standard-library/type
Runtime type validation for PHP built on the Parse, Don't Validate principle: coerce and assert unstructured input into well-typed data, with clear errors when values don't match.
Runtime type validation implementing Parse, Don't Validate - coerce and assert unstructured input into well-typed data
Frequently asked questions about Type
- How do I install php-standard-library/type in a Laravel application?
- Install it with Composer using composer require php-standard-library/type. It is pure PHP and does not require a native extension or a Laravel service provider. After installation, call its parsers or assertions at your application boundary and wrap them in Laravel-shaped helpers if you want a consistent integration.
- Does php-standard-library/type work with Laravel 8, 9, 10, and 11?
- The package is framework-agnostic rather than tied to a specific Laravel release, so Laravel version support mostly depends on your PHP version. Verify the package's PHP floor against your fleet, because older Laravel 8 or 9 applications may be excluded. Also confirm that the split package's version line stays in lockstep with the main php-standard-library monorepo.
- What is the difference between php-standard-library/type and Laravel's Validator?
- Laravel's Validator checks whether user input is acceptable against rules and returns validated arrays; it does not produce typed domain values. php-standard-library/type parses and asserts input into well-typed values at the boundary. The two are orthogonal: use Laravel validation for request rules and type parsing for the typed object your core logic receives.
- How do I use php-standard-library/type with Laravel form requests?
- Use the package inside a form request or a small ParsedRequest base class after Laravel's normal validation has accepted the payload. Parse the input into typed values there, then pass only those values into your controllers, actions, or jobs. There is no out-of-the-box Laravel service provider or facade, so this glue code is yours to own and document.
- How do I convert php-standard-library/type failures into a Laravel 422 validation error?
- Catch the package's assertion or parsing exceptions at the boundary and translate them into Laravel's ValidationException or an HTTP 422 response. Do not let raw parsing failures escape as 500 errors. A small helper, middleware, or base request class keeps that mapping consistent across endpoints.
- Is php-standard-library/type safe to use in production Laravel apps?
- The code comes from a long-running, actively maintained standard-library monorepo, so code quality is not the main concern. The production risk is provenance opacity: the split repo has one star and zero dependents, which tells you little about real usage. Pin versions, review releases in the main repository, and assign someone to changelog and CVE triage before adopting it broadly.
- What are the coercion risks when using php-standard-library/type?
- Coercion is the package's point and its sharpest edge: coercive parsers can silently accept values such as "0", "false", or an empty array when a stricter contract was intended. Adopt a written convention that allows coercion only at the outermost boundary and uses strict assertions everywhere inside. This keeps the Parse, Don't Validate model from weakening your internal type guarantees.
- How does php-standard-library/type compare with other PHP validation or assertion libraries?
- Compare options on whether they produce typed values rather than only pass/fail validation, how explicitly coercion is controlled, and how failures map to Laravel's ValidationException. php-standard-library/type is framework-agnostic and boundary-focused, so it complements Laravel's Validator rather than replacing it. Avoid adopting any such library globally if PHP 8.1+ types, readonly properties, and PHPStan or Psalm already cover the same risk.
- How should I test php-standard-library/type parsing in a Laravel application?
- Unit test your parsers with valid payloads, malformed payloads, and the coercion cases you intend to allow. Add feature tests around the Laravel boundaries where parsing happens, such as form requests, webhook ingestion, queue jobs, and decoded JSON responses. Assert that invalid input becomes a 422 or ValidationException instead of a 500.
- Is php-standard-library/type actively maintained, and what about bus factor?
- It is a split package from a long-running, actively maintained standard-library project, but the split repository itself has a misleading popularity signal: one star and zero dependents. The effective bus factor is a single-maintainer ecosystem project, which is a sustainability judgement rather than a code-quality verdict. Subscribe to or check the main repository's releases, since the split release notes mostly point there.
Weaver
How can I help you explore Laravel packages today?