Product Decisions This Supports
- Build vs. buy (or build vs. fork) for internal tooling. Model discovery is the kind of capability that shows up as a "small" line item in half a dozen features. This package lets you scope those features without committing engineering time to plumbing. Realistic build cost is low (a directory scan plus reflection), so the honest framing is "adopt to prototype, fork to ship."
- Roadmap scoping for admin/ops surfaces. Any feature that needs to answer "what entities exist in this app?" — admin CRUD scaffolding, data browsers, schema/ERD viewers, bulk export or GDPR deletion tools, seeding and factory coverage checks, audit-log coverage, permission matrices — can be unblocked cheaply if model enumeration is a solved primitive.
- Data governance and compliance features. Requirements like "export or purge all personal data for a user across every model" depend on an authoritative model inventory. A runtime discovery utility makes that inventory a code-level fact rather than a spreadsheet that drifts.
- Legacy and platform inventory decisions. Deciding what to deprecate, which models lack factories/tests/policies, or which packages ship models into the host app is much easier with automated enumeration than with grep-and-hope.
- Test and CI investment. Enabling a check that fails when a new model is added without a factory, policy, or migration gives you a cheap quality gate — a concrete, defensible item for a quarterly engineering-health goal.
- Buy-vs-extend signal for the dependency portfolio. With 0 stars, 0 dependents, and a last release in March 2023, this is not a dependency you "standardize on." Treat it as a reference implementation that informs your build decision, not as a vendor relationship.
When to Consider This Package
Consider it when all of the following hold:
- The need is internal or tooling-adjacent, not a customer-facing critical path.
- You need enumeration only — you do not need relationship graphs, schema introspection, or migration-aware metadata. (For those, evaluate a maintained ERD/schema package or
doctrine/dbal-style introspection instead.)
- You are on a Laravel version contemporary with its 2023 release (roughly Laravel 9–10, PHP 8.1+). Verify compatibility explicitly against your target version; do not assume it works on newer Laravel majors without a spike.
- You are prepared to vendor or fork it. At 0 stars and 0 dependents there is no community, no issue triage, and no security response. MIT license makes forking trivially legal; treat the fork as the real deliverable.
- You will cache the result. Filesystem scanning on a per-request basis is a latency and deploy-artifact risk (e.g., cached config, read-only containers, or a
vendor/ that looks different in production than locally). A cached manifest built at deploy time is the safe pattern.
Look elsewhere or build in-house when:
- You need a maintained dependency with a security posture, changelog cadence, or someone to call. There is none here.
- The feature is multi-tenant or package-heavy, where "find all models" must resolve per-tenant namespaces, service providers, or dynamically registered paths — verify before committing.
- You need it on a request hot path or in a queue worker where a stray scan is unacceptable.
- You are deciding whether to add a dependency for a capability you could write in an afternoon. For a scan-and-reflect utility, the maintenance overhead of a third-party package frequently exceeds the code it replaces.
How to Pitch It (Stakeholders)
To executives: This is a tiny, MIT-licensed utility that automatically lists every data model in our Laravel application. It costs effectively nothing to trial and unlocks a class of low-effort internal features — admin data browsers, compliance export/purge tooling, and automated checks that new models come with the tests and policies we require. The material caveat is maturity: zero community adoption and no release since early 2023, so we should treat it as a reference implementation to fork, not a dependency to standardize on. Recommendation: a time-boxed spike (1–2 days) to validate on our Laravel version, then a decision to vendor the ~small amount of logic we actually need.
To engineering: The capability is model enumeration — likely a filesystem scan plus class reflection over your configured model paths. It is a primitive, not a framework. Before adopting: confirm it works on our Laravel/PHP version, confirm the enumeration is cacheable, and confirm behavior in production where the filesystem is read-only and vendor/ may be pruned. Given the zero-maintenance risk, the default plan should be to read the source, reimplement the parts we need behind our own small interface, and keep the package out of composer.json. That gives us the same feature with no supply-chain or upgrade liability, and lets us swap in better tooling later if requirements grow to relationship graphs or schema introspection.