Weave Code
Php Checker Laravel Package
ixnode/php-checker
ixnode/php-checker is a lightweight PHP package offering reusable checker utilities for validating common data types and conditions. Its simple, focused methods help keep validation logic clean, readable, and consistent across Laravel and plain PHP projects.
A collection of various PHP types check classes.
Frequently asked questions about Php Checker
- What is ixnode/php-checker used for?
- It is a lightweight, framework-agnostic PHP utility for reusable value and input checks, such as guards, form handling, and defensive code. It returns simple, predictable results that fit naturally into if conditions. In Laravel it can be used directly in custom validation rules, form requests, or service-layer guards.
- How do I install ixnode/php-checker in a Laravel project?
- Install it with Composer using composer require ixnode/php-checker. No service provider, config file, assets, or migrations are required. You can then use the checker classes directly wherever you need boolean checks on input values.
- Does ixnode/php-checker work with Laravel 9, 10, and 11?
- It is framework-agnostic and does not impose Laravel version constraints, so it composes cleanly with Laravel 9, 10, and 11. You should still confirm the PHP version floor in its composer.json for your environment. There are no Laravel-specific runtime requirements to negotiate.
- Do I need a Laravel service provider or config file for ixnode/php-checker?
- No. The package is a low-coupling Composer dependency with no service provider requirement, no config surface, and no persistence concerns. It slots in wherever you need true-or-false checks on input payloads, including custom rules and service-layer guards.
- Why were checkSimple and checkIndexArraySimple renamed in ixnode/php-checker 0.1.8?
- Version 0.1.8 renames CheckerArray::checkSimple to checkSequential and CheckerArray::checkIndexArraySimple to checkIndexArraySequential. The release provides no deprecation shim or alias and was shipped as a patch on the 0.1.x line without a major-version bump. Existing callers of the old names can therefore fail at runtime rather than at install time.
- Is ixnode/php-checker 0.1.8 a breaking change if I use a caret constraint?
- Yes, a caret constraint like ^0.1 can silently pull 0.1.8 because it is a patch release on the 0.1.x line. If your code still calls checkSimple or checkIndexArraySimple, it may fatal at runtime on the request path. Pin the exact version 0.1.7 until the rename is validated, or adopt 0.1.8 as your new baseline and update call sites.
- How should I migrate from checkSimple to checkSequential in a Laravel app?
- Search for checkSimple and checkIndexArraySimple across app, tests, and custom Rule classes, then update call sites to checkSequential and checkIndexArraySequential. The release notes suggest an identifier-only change with no signature or return-type change, but verify behavior with your test suite. Consider wrapping the library in an internal adapter such as App\Support\ArrayChecker to decouple application code from its unstable public surface.
- Can ixnode/php-checker replace Laravel's Validator or form requests?
- No. It does not compete with Laravel's Validator and is not a full request-validation framework. Use Laravel's built-in Validator and form requests for request validation, and use this package for lightweight boolean checks, guards, and defensive code where appropriate.
- How do I test an ixnode/php-checker integration with PHPUnit or Pest?
- Unit-test the checker methods and any renamed call sites with PHPUnit or Pest, asserting the expected true-or-false outcomes. If you add an internal adapter, test that wrapper rather than scattering direct package calls through the application. Run the suite after any Composer update to catch runtime failures from renamed symbols.
- Is ixnode/php-checker safe for production and how is it maintained?
- It is pre-1.0 with an unstable public surface, terse documentation and changelog, and no visible semantic-versioning policy. Ongoing operational cost is low because there are no services or schema concerns, but upgrade vigilance is high for a package that ships breaking renames in patch releases. For production, pin an exact version, wrap it in an internal adapter, and relax the constraint only after a 1.0 release or an explicit stability commitment.
Weaver
How can I help you explore Laravel packages today?