Event Bundle Laravel Package

Product Decisions This Supports

• Roadmap / build-vs-buy for domain-discovery tooling. Release 0.1.13 adds a scan capability that locates entity classes by walking the project directory, and correctly resolves entities across multiple entity managers. That upgrades the package from "works if your project is shaped a certain way" to "works on the projects we actually have." It is a candidate to buy/adopt rather than build: a naive directory walk is a day of work, but correct resolution across several entity managers (namespaces, mapping drivers, proxies, inheritance) is where custom implementations quietly rot.
• Feature enablement. Anything that needs a programmatic list of entities is now cheaper: ERD/schema documentation generation, onboarding "domain model" views, orphaned/unmapped-entity CI checks, admin or debug surfaces, migration-diff tooling, and scaffolding commands.
• Multi-EM support is a product-level unlock, not a footnote. Multi-tenant databases, modular monoliths with per-module connections, and legacy-DB splits are exactly the architectures where hand-maintained entity lists break first. This release moves the package from single-EM hobby projects into those setups.
• Dependency posture. Still 0.1.x. Treat as internal enablement tooling, not a platform dependency, and budget for API churn.

When to Consider This Package

Adopt when:

• You run Doctrine ORM inside Laravel and have one or more entity managers — the second manager is where this release earns its keep.
• You currently keep a manually curated list of entity classes (in config, a command, or CI) and it drifts.
• You need entity discovery as an input to another tool (docs, audits, CI gates) rather than as an end-user feature.
• You can pin a 0.x version and wrap the call site behind a thin internal interface.

Look elsewhere when:

• The stack is Eloquent-only; entity classes are not a concept you have.
• You have a single entity manager with a rigid, conventional namespace — a short glob or a Composer classmap read may be enough, and a dependency isn't justified.
• You require a stable public API, semver guarantees, or vendor support. Wait for 1.0.
• Entities are registered dynamically at runtime or via non-standard mapping drivers; confirm the scanner actually sees them before committing.
• Discovery would run on a hot path. Filesystem scanning must be cached, not executed per request.

Release-specific note: 0.1.13 is additive and non-breaking — a new method plus broader resolution. No deprecations or migration work implied. It changes the eligibility calculus, not the risk profile.

How to Pitch It (Stakeholders)

Executives: Low-cost, low-risk internal tooling that removes manual bookkeeping from our domain-model workflows. It matters more as we add databases, modules, or tenants — the exact situation where our hand-maintained lists fail. Not customer-facing; no material licensing or lock-in exposure.

Engineering: One call gives you the project's entity classes, resolved correctly across multiple entity managers — the edge case we'd otherwise hand-roll and maintain. Pin the version and keep the call behind a small internal wrapper so a 0.x API change is a one-file fix. Cache scan results; don't scan on every request.