Filterus Laravel Package

Technical Evaluation

Architecture fit

ircmaxell/filterus is a single-purpose, dependency-light filtering/validation library that predates many of the conventions now standard in the Laravel ecosystem. Architecturally it is a good fit only where you want a small, stateless, chainable filter API that can be used outside of Laravel's Validator pipeline — for example, normalizing and asserting invariants inside domain objects, DTOs, or value-object constructors rather than at the HTTP boundary. Its functional style (Filter::factory(), ->validate(), ->filter(), nested and per-element filtering) is composable and easy to reason about. Where it does not fit cleanly is at the framework's request-validation layer: Laravel's Validator, FormRequest, and rule objects already cover most of the same ground with better localization, error messaging, and framework integration. Treating this package as a replacement for the framework validator would create two competing validation paradigms in the codebase with no clear ownership boundary.

Integration feasibility

Installation is a standard Composer dependency with no service provider and no framework coupling, so wiring it in is low-effort: a container binding or facade is sufficient. The real feasibility question is version compatibility, because the package was authored in the PHP 5.3/5.4 era and the repository is not clearly identified in the metadata we have, which makes it hard to verify the current state of the source of truth. Concretely, we would need to confirm: PHP version constraint and whether it runs cleanly on PHP 8.x, autoloading standard (PSR-0 vs PSR-4) and any classmap conflicts, whether it emits deprecation notices or relies on removed dynamic-property / each()-era behavior, and whether its PHPUnit suite still executes. Because validation is security-adjacent, integration without a green test run on our target runtime is not acceptable.

Technical risk

• Maintenance status. 443 stars and an "unknown" repository reference is a weak supply-chain signal. The project is effectively unmaintained; there is no evident release cadence, CVE process, or responsive maintainer.
• Runtime drift. A pre-PHP-7 library used in a modern Laravel app carries real risk of deprecation noise, type-coercion differences, and edge-case behavior changes on PHP 8.x.
• Security surface. Filtering/validation is exactly the layer where subtle divergence from framework expectations becomes an input-handling vulnerability. Silent coercion (e.g., string-to-int, array filtering) must be understood before it touches untrusted input.
• Redundancy. Much of the capability overlaps with filter_var, Symfony Validator, and Laravel's own rules. Duplicate mechanisms increase cognitive load and audit scope.
• Vendoring risk. If we adopt it, we likely own it. That needs to be an explicit decision, not an accident.

Key questions

1. What is the canonical repository, and is there a maintained fork or successor?
2. Does the test suite pass on our target PHP version and Laravel release, CI-verified?
3. What is the license, and are we comfortable with the obligations?
4. Which specific use cases justify adding it over filter_var / Laravel rules — and can we name three that the framework cannot serve?
5. Are we prepared to fork and vendor it, with a named internal owner, if upstream stays dormant?
6. Has anyone performed a security review of the filter implementations, particularly around type juggling and array/recursive filtering?

Integration Approach

Stack fit

Best fit is a narrow, deliberate role: a domain-level filtering utility for normalizing and asserting invariants in value objects and import/ETL pipelines, where its compact chainable API is genuinely nicer than hand-rolled checks. Poor fit is the HTTP request-validation path, where Laravel's FormRequest/Validator already provides error bags, localization, and rule extensibility. The pragmatic positioning is "adjacent to, not instead of" the framework validator.

Migration path

Adopt behind an anti-corruption layer rather than calling the library directly. Define a small internal interface (e.g., InputFilter::normalize() / InputFilter::asserts()), implement it with filterus, and bind it in the service provider. This gives three benefits: call sites never reference the third-party namespace, swapping to a fork or to native filter_var is a one-file change, and we can write our own contract tests that pin expected coercion behavior. If a maintained fork emerges, only the adapter moves.

Compatibility

Gate adoption on a compatibility spike: install in a scratch branch, run the upstream test suite plus our own contract tests on every PHP version in the support matrix, and capture deprecation output. Confirm autoloading does not conflict with Composer's optimized classmap. Verify behavior for the specific filters we intend to use (string, int, float, regex, email, array, nested) rather than assuming suite-level green means feature-level safe. Any filter we cannot get green gets excluded from the allowlist.

Sequencing

1. Discovery — locate canonical source, pin a commit hash, record license and last-commit date.
2. Compatibility spike — PHP matrix test run, deprecation audit, documented behavior table for the filters we plan to use.
3. Adapter build — internal interface plus filterus-backed implementation, with contract tests.
4. Pilot — one low-blast-radius consumer (e.g., a CSV import normalizer or a single value object), behind a feature flag.
5. Review gate — confirm no divergence from framework validation behavior, no perf regression, no unexpected coercion.
6. Broader rollout or vendor/fork decision — either expand usage or, if upstream is confirmed dead and the pilot succeeded, formally fork into an internal namespace with an owner.

Operational Impact

Maintenance

This is the dominant cost. Expect to own the dependency: vendor it, pin it, and budget for periodic review of PHP-version compatibility. Without an upstream maintainer, "no releases" is not stability — it means latent breakage surfaces only when we upgrade PHP or Laravel. Assign a named owner and add it to the tech-radar review cadence. Vendoring adds a small ongoing sync burden but removes the surprise factor of an abandoned Packagist entry.

Support

Community-only, best-effort, no SLA. Internal engineers will be the de facto support channel. Mitigate by keeping the adapter surface small and documentation tight — a one-page behavior reference for the filters in use pays for itself the first time someone debugs an unexpected coercion in production.

Scaling

Runtime cost is negligible: the library is stateless, in-process, and does no I/O, so horizontal scaling is unaffected. The scaling concern is organizational, not computational — every additional consumer of the library widens the audit surface and increases the cost of a future migration.

Failure modes

• Silent coercion — a filter normalizes input in a way the caller did not intend, producing a valid-looking but wrong value. Detect with contract tests, not production.
• Deprecation-to-error escalation — PHP upgrades turn warnings into exceptions across many call sites at once. Contain by isolating behind the adapter.
• Autoload/namespace collision — especially if an unmaintained PSR-0 layout is loaded alongside modern packages.
• Abandonment drift — no security response if a flaw is found in the filter logic; we inherit the remediation work.
• Paradigm split — two validation systems in one codebase, with engineers unsure which is authoritative for a given input. Mitigate with a written rule: framework validator at the boundary, filterus inside the domain.

Ramp-up

Low for engineers. The API is small, chainable, and readable; a competent Laravel developer is productive within an hour. The real ramp-up cost is conceptual, not syntactic: teams must learn when to reach for this versus the framework validator, and must internalize the coercion semantics of each filter they use. Budget a short internal write-up and a code-review checklist entry rather than formal training. Given the low opportunity score in the metadata, treat adoption as a deliberate, contained bet — justified only if the pilot demonstrates a concrete gap the framework cannot fill — rather than a default choice.