Laravel Ec Validator Laravel Package

Technical Evaluation

Architecture fit. The package is architecturally well-behaved and idiomatic Laravel. It ships a single auto-discovered service provider (EcValidatorServiceProvider), registers a custom validator via Validator::resolver() in boot(), and exposes four string rules (ecuador:ci, ecuador:ruc, ecuador:ruc_spub, ecuador:ruc_spriv). There are no migrations, no published config, no queues, no I/O, and no global state beyond the validator resolver itself. Validation logic is delegated to a sibling library (tavo1987/ec-validador-cedula-ruc ^2.0), so the Laravel layer is a thin adapter — a good separation of concerns, and one we could replicate ourselves if needed.

The fit is narrow but real: this only makes sense for a Laravel application serving the Ecuadorian market where Cédula/RUC capture happens (onboarding, KYC, invoicing, supplier registration). If we run non-PHP services (Node admin, Python data pipeline) that must apply the same rules, this package does not help them — the algorithm gets duplicated and diverges.

Integration feasibility. High. composer require tavo1987/laravel-ec-validator and use the rule strings in FormRequests. Realistic effort is well under a day for a working integration. The interesting work is not installation, it is establishing confidence in correctness and deciding how hard we bind to the package.

Technical risk. The dominant risk here is supply chain and correctness confidence, not code quality:

• Adoption signal is effectively zero — 6 stars, 0 dependents, single maintainer. The repository's 19.7 score reflects ecosystem signal, not implementation quality; but with no downstream consumers, there is no independent evidence that the rule set holds against real-world edge cases (border-province RUCs, recently issued entity types, SRI rule changes).
• Correctness is business-critical in both directions. A false negative rejects a legitimate customer at signup — a support ticket and lost conversion. A false positive lets an invalid tax ID into invoices/filings, which surfaces later and externally. Neither is catastrophic; both are silent.
• Poor error semantics. Per the guidelines, an unrecognized rule parameter throws PHP's Error rather than an InvalidArgumentException or a validation failure. In production that becomes an unhandled 500 rather than a validation message, and Error is a class most framework error handlers and our own catch (Exception) blocks will not catch. This is the single most concerning implementation detail and it should be verified and, if confirmed, wrapped or patched.
• Global validator resolution. Calling Validator::resolver() is a process-wide override. Any other package using the same pattern is a last-one-wins collision that silently disables these rules. Must be verified against the actual dependency set.
• Two-deep dependency chain. The core logic lives in a second package by the same author, pinned ^2.0. A 3.0 release is a breaking change we do not control.
• Magic strings. Rule names are strings with no constants or enum; typos fail at runtime, in one code path, possibly only in production.
• Support matrix is narrow. PHP ^8.2 and Laravel ^11|^12 only. Laravel 10 and 13 are both excluded today, and L13 support depends on a maintainer who may not be active.
• Metadata anomaly: the recorded last release (2026-10-22) is in the future. This is likely a data error, but it means release cadence cannot be inferred from the scorecard and must be verified on Packagist directly.

Key questions to resolve before committing:

1. Does a real, anonymized golden set of Cédulas and all three RUC sub-types pass — including border/edge cases and inputs with whitespace, hyphens, or leading zeros?
2. What exactly is thrown on a bad rule parameter, and does it reach our HTTP error handler as a 500?
3. Does anything else in our stack call Validator::resolver()?
4. Is the maintainer responsive (issue/PR history in the last 12 months), and is there a stated L13 plan?
5. Does the package normalize input, or must we trim/strip separators before validation?
6. Are error messages localizable to Spanish out of the box?
7. Has the SRI changed any RUC rule since the core library's last release?

My recommendation: treat this as buy-to-learn, then decide. The Ecuadorian validation algorithm is small and well-specified (modulus checks over province code, entity type, and check digit). A one-to-two-day in-house reimplementation with the golden test set is a credible alternative that eliminates a two-deep dependency chain and the Error-throwing behavior entirely. The package is a fast way to get a correct reference implementation and test corpus; it is not obviously the right thing to run in production permanently.

Integration Approach

Stack fit. Compatible if we are on Laravel 11 or 12 with PHP 8.2+. If the target application is on Laravel 10 or PHP 8.1, the package is blocked as-is and the choice collapses to fork-and-repin or reimplement. Confirm the platform version before anything else — this is the first gate.

Migration path. Greenfield adoption is trivial. The realistic case is replacing an existing regex:^[0-9]{10}$-style check, and that must not be a hard cutover:

1. Add the package alongside the existing rule.
2. Run both validators in shadow mode on production traffic for one to two weeks, logging disagreements per rule.
3. Treat every disagreement as a test case: either the old rule was too permissive (expected, this is the win) or the package is producing false negatives (a blocker).
4. Cut over only when the disagreement set is empty or fully explained.

Compatibility and containment. Two containment measures are non-negotiable regardless of which implementation wins:

• Wrap the rules. Do not let ecuador:ci and friends appear in FormRequests across the codebase. Introduce a single in-house rule class (e.g. Rules\EcuadorianId) that internally delegates to the package or to our own implementation. This makes a vendor swap, a fork, or a full replacement a one-file change and gives us one place to normalize input and localize messages.
• Handle the failure mode. Wrap usage so a bad rule parameter or an unexpected Error cannot escape as a 500. Either patch via fork or guard at the rule boundary.

Accept the global Validator::resolver() behavior only after confirming no other package competes for it; if there is a conflict, the wrapper approach plus a Laravel-native Rule object may be preferable to the string-rule registration entirely.

Sequencing.

Step 4 is the one most teams skip. Given the size of the domain logic and the supply-chain profile here, it is cheap insurance and it doubles as our contingency plan if the maintainer goes dark.

Operational Impact

Maintenance. Ongoing effort is genuinely low — the package is a stable adapter over a stable algorithm — but it is not zero and it is not under our control. Laravel major releases (L13, L14) will require a maintainer release; the current constraint ^11.0|^12.0 guarantees a hard stop at the next major unless someone publishes an update. Plan on an annual review and hold a documented fork-and-repin contingency. Budget roughly a day a year, plus the tail risk of an unplanned fork if a Laravel upgrade lands before the maintainer acts.

Support. Community-only, no SLA, one maintainer, minimal issue history. Internal documentation is the actual support mechanism: record the rule semantics, the RUC sub-type distinctions, the golden test set, and the escalation path (fork → reimplement). Any engineer touching onboarding, KYC, or invoicing must know the wrapper exists and that the dependency is thin.

Scaling. A non-issue. Validation is pure CPU work measured in microseconds with no network, disk, or database access. It is safe in high-volume paths including bulk import — a million-row CSV import will not be meaningfully slower. The only scaling consideration is keeping it out of database query construction; it belongs in request/import validation, never in a query builder callback.

Failure modes. Ranked by expected pain:

1. False negative on a valid ID — customer blocked at signup or a supplier cannot be registered. Customer-visible, support-visible, and hard to distinguish from user error. Highest-frequency real-world impact.
2. False positive — invalid tax ID persisted, surfacing downstream in invoicing or SRI-facing processes. Low frequency, high cleanup cost.
3. Unhandled Error on a bad rule parameter — a 500 instead of a validation message. Trivially triggered by a typo during a refactor; this is the one to fix before shipping.
4. Resolver collision — rules silently unavailable; every ID passes or every ID errors depending on the collision. Silent, only detectable by test coverage.
5. Dependency drift — a ^2.0 minor of the core library changing behavior under us, or an unmaintained package blocking a framework upgrade.
6. Input not normalized — whitespace or hyphens cause rejection that users perceive as arbitrary. Handle in the wrapper.
7. Untranslated error messages — English validation messages for Spanish-speaking end users. Cheap to fix, embarrassing to miss; own the message strings in the wrapper.

Mitigation across the board: instrument it. Emit a counter per rule and outcome (pass/fail) and alert on rate discontinuities. A sudden shift in ecuador:ruc rejection rate is the earliest and often only signal that a library release, a data-entry change, or a client rollout has broken something.

Ramp-up. Low. One engineer, a few hours to productivity, with the real learning being Ecuadorian domain knowledge (the difference between a natural-person RUC, a public-company RUC, and a private-company RUC, and why they need separate rules) rather than anything about the package API. That domain knowledge is the durable asset — capture it in the wrapper's tests, not in tribal memory.