Ci Validators Laravel Package

Getting Started

The new tag changes the headline, not the fundamentals. 1.0.16 is a real release, and the fact that it is a patch number sixteen implies a longer tag history than the "single release from 2018" reading suggested. Before anything else, re-run the metadata check — the premise you were working from was incomplete:

composer show --all is/ci-validators

That gives you the true tag list, the release dates, and the require constraints of the current tag. The one-word changelog ("Autowire") tells you the theme of this release but nothing about version support, so the source is still your first read, not the README.

Step 1 — Confirm it installs, and read the constraints on the new tag.

composer require is/ci-validators --dry-run

Then open vendor/is/ci-validators/composer.json. Two questions: did 1.0.16 widen the illuminate/* constraints, and does it still auto-discover via extra.laravel.providers? A patch release that only touches wiring usually does not bump the framework floor, so if you are on Laravel 10/11 and the constraint still caps at 5.x, installation will still be blocked and that is still the correct outcome.

Step 2 — Find what "Autowire" actually changed.

Diff the new tag against the previous one before reading anything else:

git diff <previous-tag> 1.0.16 -- src/

The likely shape is that rules are now resolved through the container ($this->app->make(...)) instead of new, which means constructor injection into rule classes now works. Confirm whether that resolution happens in the service provider, in a Validator::extend closure, or per-validation. That single fact determines everything in the Implementation Patterns section below.

Step 3 — Your first use case is unchanged: gate the repo's own CI artefacts.

Validate composer.json, .env.example, deployment descriptors, phpunit.xml before they reach master. A Form Request for an internal admin screen works, but an Artisan command is the better first integration:

// app/Console/Commands/ValidateCiConfig.php
$data = json_decode(file_get_contents(base_path('composer.json')), true);

$validator = Validator::make($data, [
    'require.php' => ['required', 'string'], // plus the package's rule(s)
]);

if ($validator->fails()) {
    $this->error($validator->errors()->first());
    return 1; // fail the pipeline
}

Run it ahead of the test suite in GitHub Actions or GitLab CI. A non-zero exit code is the entire value proposition, and it is the pattern you will use most often.

Implementation Patterns

Constructor injection is now the interesting pattern — if the diff confirms it. If Autowire means rules are built by the container, you can type-hint dependencies in a rule instead of reaching for facades:

class CiPhpVersionRule implements Rule
{
    public function __construct(private Repository $config) {}

    public function passes($attribute, $value): bool { /* ... */ }
}

Verify it with app()->make(CiPhpVersionRule::class) before you rely on it. If that throws BindingResolutionException, autowiring is either not in this release or not applied on the path you are using, and you are back to the pre-1.0.16 position.

Validate before you persist, not after. A FormRequest whose rules() merges the package rules with your own remains the ergonomic integration. Keep the package rules in a wrapper method so a future fork is a one-line swap — this matters more than usual for a package whose only signal is a patch tag.

private function ciRules(): array
{
    return [
        'php_version' => ['required', /* package rule here */],
    ];
}

Compose with Rule:: for conditional checks. Rule objects still compose cleanly with Rule::when(), bail, and required_if. They do not know about each other unless the source says so.

Drive it from a console command for CI. Anything "daily" is better as php artisan ci:validate than a web form: testable with $this->artisan()->assertExitCode(1), identical locally and in the pipeline, and independent of the HTTP stack surviving the next framework upgrade.

Run it as a pre-commit hook. The rules are still pure PHP; a hook that boots a minimal console kernel and validates staged config files is cheap and catches breakage before the PR exists.

#!/bin/sh
php artisan ci:validate || exit 1

Test the rules, not the package. Feature tests asserting what your application considers valid are your regression insurance if you later fork or drop the dependency:

public function test_rejects_invalid_ci_descriptor(): void
{
    $this->post('/admin/ci-config', ['php_version' => 'nonsense'])
        ->assertSessionHasErrors('php_version');
}

Pin the minor line, vendor the source. composer require is/ci-validators:1.0.* — never floating. For production, copy the rule classes into app/Rules/ with attribution. A fresh patch tag is not a maintenance guarantee; it is one commit.

Gotchas and Tips

A new tag is not the same as active maintenance. Zero stars and zero dependents are still true. One release titled Autowire does not tell you whether there will be a 1.0.17, whether there is a security policy, or whether issues get answered. Treat 1.0.16 as evidence that someone still cares, not as evidence that the project is healthy. Budget for it to become your code; the fork cost is an hour.

Check whether the tag lineage is consistent. The previous reading said one release in 2018; 1.0.16 implies sixteen patches. Either the metadata was truncated, the repo was re-tagged, or this is a fork published under the same name. Diff the tag against its predecessor and look at the commit author before you conclude anything about support.

Autowiring fails at resolution time, not at boot. An unbound constructor parameter surfaces as a BindingResolutionException the first time the rule is constructed — which may be inside a validation call, in a queued job, or in a request, far from the cause. If you see a 500 instead of a 422 after this release, suspect rule construction, not rule logic.

Autowiring can silently bypass your registration. If you registered the rule yourself with Validator::extend('ci_rule', fn(...) => (new TheRule)->passes(...)), you are still calling new and the container never sees it. Check both paths — the package's own registration and yours — before assuming the feature is missing.

Watch for singleton-scoped rule state. Container-resolved rules are new instances per make() by default, but if 1.0.16 binds them as singletons, any per-validation state on the rule object will leak across validations in a long-running worker. Test two validations in one process with different inputs.

Laravel version drift remains the primary failure mode. The Rule contract changed shape between 5.7 and 11, Validator::extend implicit-rule behaviour was refined, and provider methods gained return types. Expect to fix missing : void, deprecated implements Rule string interfaces, and $this->translator usage. Smoke-test with a trivial Validator::make(['x' => 'y'], ['x' => [new TheRule]]) — a green result tells you the class loads and resolves.

Error messages are almost certainly untranslated. Look for resources/lang or lang. Hard-coded strings in message() cannot be localised without editing the class — another argument for vendoring. Translation keys can be published with vendor:publish; a typo'd namespace silently renders the raw key in your UI rather than erroring.

String rules need registration to exist at all. If the validators are string-based ('ci_php_version'), they only work after the provider has run Validator::extend. Calling Validator::make() before boot, or in a queued job where the provider is skipped, produces "validation rule not found" — an ordering bug that looks like a typo. Rule objects avoid this; prefer them.

Debug by constructing the rule directly. When a rule fails on input you believe is valid, bypass the validator:

dd(app()->make(TheRule::class)->passes('field', $value)); // if autowired
dd((new TheRule())->passes('field', $value));            // if not

The difference between the two lines also tells you whether Autowire is live in your install. This separates "the rule is wrong" from "my resolution path is wrong", which are different problems producing the same 422.

Watch for implicit rules and empty input. A rule that should reject null never fires unless registered implicit. This is the most common "the rule doesn't run" report with third-party validators. Test explicit null before blaming 1.0.16.

Extension points are limited but real. A published config file is your only supported customisation. If one exists, publish it and read every key. If not, do not patch vendor/ — fork to a VCS repository in composer.json ("repositories": [{"type": "vcs", "url": "..."}]) so the change reproduces on every machine and in CI.

Reassess versus writing your own — the calculation has not changed much. Three or four Rule classes, roughly 80 lines, an afternoon, owned forever. Autowiring makes the package slightly more pleasant to consume, but it does not change the ownership maths. If the rules encode domain-specific CI semantics you would not think to write, vendoring wins. If they are thin wrappers over filter_var and version comparisons, write your own and delete the dependency — it will outlive the package by a decade.