Entity Exist Laravel Package

Technical Evaluation

Architecture fit. The package is a Symfony Validator constraint backed by Doctrine ORM — not a Laravel package. It is applied as an attribute/annotation on Doctrine entities and resolved by a ConstraintValidator holding an EntityManager. Laravel's validation pipeline is illuminate/validation, where rules implement ValidationRule::passes($attribute, $value) and are resolved from the container. There is no shared extension point: a Symfony constraint cannot be registered with Laravel's validator without bridging the entire Symfony Validator component. Framework mismatch, not a wiring gap.

Integration feasibility. To use it as-is we would pull in symfony/validator, doctrine/orm, and a second persistence layer running alongside Eloquent — dual ORM, dual connection config, dual migration story — to obtain behavior Laravel already ships natively (exists:table,column, unique, Rule::exists()->where()). Feasibility as-is: low. The semantics are reproducible as a custom Laravel rule in roughly 50 lines.

Technical risk.

• Maturity: 1 star, 0 dependents, no production evidence anywhere. Nothing validates the edge cases we care about.
• Bus factor: effectively 1, no community triage, no issue-response history to inspect.
• Release metadata: the stated last release (2026-07-05) is ahead of the current date — either a metadata anomaly, a backdated tag, or a pre-release. Must be verified before any pin.
• Licensing: MIT, clean.
• Semantics risk: existence checks are security-sensitive (tenant isolation, soft deletes, authorization). Delegating that to an opaque, unaudited package is a governance problem regardless of code quality.

Key questions.

1. Do we actually operate any Symfony + Doctrine services, or is this a Laravel-only evaluation? (If Laravel-only, the evaluation ends here.)
2. What does this give us that Rule::exists()->where() does not?
3. Does the constraint support scoping — tenant, soft-delete, status, ignore ID? How is it configured and is it fail-closed?
4. What happens when the EntityManager or DB is unavailable — validation error or infrastructure error?
5. What is the versioning policy? Are we pinning a 0.x with no BC guarantees?
6. Result of composer audit and any advisory history on the maintainer?

Integration Approach

Stack fit. Poor for Laravel. Good only for Symfony 5/6/7 + Doctrine ORM 2/3.

Migration path. Do not adopt. Build an internal equivalent that mirrors the intent with explicit, auditable options:

• A ValidationRule implementation accepting a model class or repository contract (not a raw table string).
• Options: target column, ignore-ID for updates, additional where constraints, withTrashed/onlyTrashed, and tenant scope derived from authenticated context.
• Ship it as a small internal package (or app/Rules) so every service shares one implementation and one audit surface.

Compatibility. If a legacy Symfony service exists, it can consume this package — keep that isolated to that repo and do not attempt to share it across the framework boundary. Cross-framework reuse would be via a validation contract we own, not via the library.

Sequencing.

1. Spike (1–2 days): confirm whether any service in the estate is Symfony + Doctrine. If no, close the evaluation and record the decision.
2. If yes: evaluate only inside that repo, pinned to a verified tag, with composer audit and a read of the validator source before merge.
3. In parallel: ship the Laravel-native rule behind a feature flag and backfill existing exists: string rules where tenancy or soft-delete semantics matter.
4. Over one quarter: deprecate ad-hoc table-string rules in favor of the shared rule.

Operational Impact

Maintenance. Adopting this in a Laravel app adds symfony/validator and doctrine/orm — an ongoing upgrade tax for two frameworks the team otherwise does not run, incurred for one validation rule. Not defensible.

Support. No vendor, no SLA, one maintainer, zero dependents means no community workarounds to lean on. Internal ownership is required from day one, which is another argument for owning the ~50-line equivalent outright.

Scaling. Every constraint evaluation is a database round trip. On bulk imports or list endpoints this becomes N queries unless batched or cached. Our internal rule should support request-scoped caching or a preloaded ID set to keep imports linear.

Failure modes.

• Error conflation: DB latency or timeouts surface as validation failures → misleading 422s where a 503 belongs. Requires explicit exception separation.
• Silent scope drift: soft-deleted or tenant-scoped rows pass or fail depending on default query scoping — the highest-severity risk here.
• TOCTOU: the constraint confirms existence at validation time, not at persist time. It is not a substitute for a database foreign key; the FK remains the real integrity control.
• Dual-ORM drift: two connection configs and two schema truths diverging silently.

Ramp-up. The library itself is small; a competent Laravel developer reads it in under an hour. The real ramp-up cost is the Symfony/Doctrine conceptual surface — EntityManager, constraint metadata, attribute vs. annotation resolution — plus the operational burden of a second persistence layer. That cost is paid permanently and buys functionality we already have.