Entity Exist Laravel Package

Product Decisions This Supports

• Build vs. buy for input validation: This package replaces a small, repetitive chunk of code — the "does this ID actually point to a real row?" check that otherwise gets hand-rolled in controllers, form types, or request validators. The decision it informs is narrow: adopt a third-party constraint versus spending half a day writing an equivalent Constraint + ConstraintValidator pair in-house.
• Feature scoping for reference-integrity UX: It lets you add friendlier validation (readable violation messages, negation via "must not exist") on top of foreign keys, so a bad reference surfaces as a form error rather than a 500 from the database. That's a UX decision — whether users see a clean message or a stack trace — not a data-integrity decision.
• API contract hardening: For endpoints that accept entity identifiers (tenant IDs, parent resource IDs, lookup keys), it standardizes the "unknown reference" error path, which is a prerequisite for consistent 422 responses.
• Roadmap de-risking on negated checks: The "assert does not exist" side is useful for pre-flight uniqueness/availability checks (e.g., "this slug is free") without writing another custom validator.
• What it explicitly does not decide: It is not a substitute for database-level foreign keys or unique constraints. Any decision framed as "this package gives us referential integrity" is the wrong decision — treat it as a validation/UX layer only.

When to Consider This Package

Adopt only if all of the following hold:

• You are on Symfony with Doctrine ORM. Despite being filed under Laravel/PHP, this is a Symfony validation constraint backed by Doctrine. On Laravel/Eloquent it is not usable without adaptation — use the built-in exists / unique validation rules instead. This alone disqualifies it for most Laravel shops.
• You have repeated ad-hoc existence checks in form types or DTOs and want them expressed as declarative constraints with translatable messages.
• You accept single-maintainer risk. 1 star, 0 dependents, and no ecosystem signal. Pin the version, keep a vendored fallback, and assume you may own it.
• The check is interactive, not bulk. These constraints typically issue a query per validation; fine for a form submission, poor for batch imports or high-volume API paths.

Look elsewhere (or write it yourself) when:

• You need race-safe guarantees — only a DB constraint closes that gap.
• You need complex predicates (composite keys, tenant-scoped existence, soft-delete semantics) that the package doesn't express.
• Your supply-chain policy requires maintained dependencies with adoption evidence; 1 star and 0 dependents will not clear review.
• You are on Laravel, or Doctrine without Symfony Validator — integration cost exceeds the ~50 lines you'd write.

How to Pitch It (Stakeholders)

To executives: A small, MIT-licensed utility that turns "that ID doesn't exist" from a crash into a clean validation message. The cost is near zero and the risk is contained by pinning the version — but it is a convenience, not a strategic capability, and it does not improve data integrity beyond what our database already enforces. Recommendation: low priority; approve only as a tactical cleanup inside an existing Symfony/Doctrine service.

To engineering: Drop-in Symfony constraint with positive and negated existence assertions over Doctrine. It removes boilerplate from form types and standardizes the unknown-reference error path. Caveats to weigh in review: it's effectively a single-maintainer package with no dependents, so we should verify Doctrine/Symfony version support, check test coverage, and be prepared to fork. If we're not already on Symfony + Doctrine, the answer is no — and even if we are, "write the 50-line validator ourselves" is a legitimate competing option that removes the dependency entirely.