Dummy Laravel Package

Product Decisions This Supports

• Build vs. buy vs. do-nothing for test-fixture tooling. This is a require-dev, MIT-licensed, zero-cost helper with no production footprint. The decision is not "invest in a platform," it's "stop hand-writing factory boilerplate or keep doing it." The defensible PM answer is pilot, then wrap or fork — never build from scratch, never mandate without evidence.

• Whether to standardize synthetic test data across a multi-repo estate. Two release signals matter commercially more than any feature: v1.1.0 dropped the hard Laravel framework dependency, and v2.0.0 renamed classes/methods specifically to avoid colliding with other packages. Together these make the package viable in shared package repos, CLI tools, and narrow queue-worker services where pulling in the full framework is a non-starter. That's an architectural affordance, not a convenience — it's what lets one decision cover many repos.

• Roadmap: treating framework-version coverage as a standing maintenance line item. The cadence is deliberate — Laravel 12 in v1.2.0, Laravel 13 in v1.4.0, plus a factory-parity track (v1.5.0 parity conveniences, v1.6.0 Eloquent factory attribute expansion). If a roadmap commitment is "a Laravel major upgrade must not block the test suite," this package has a demonstrated track record of tracking those releases quickly. That is the PM-relevant claim; the feature list is secondary.

• Developer-experience investment, judged on velocity not KPIs. It targets authoring friction directly: dynamic factory states via HasFactory (v1.3.0), generics for static analysis and IDE completion (v1.5.1), fewer bespoke fixture classes. Frame the bet as engineering time saved on fixture authoring and CI wall-clock — not on a business metric. If those don't move, the bet failed regardless of how pleasant the API is.

• Use cases worth a timeboxed spike. Seeders and demo/QA environments needing varied synthetic records without touching real customer data; feature tests requiring nested or stateful model graphs (order → payment → refund); load-test data generation where volume with shaped variability matters.

• "Do not adopt yet" is a legitimate and probably correct output. At 43 stars and 0 known dependents there is essentially no external validation, no troubleshooting corpus, and no ecosystem to lean on. For most teams the right decision is a one-sprint evaluation with a named owner — a reversible dev-dependency bet, not a mandated standard.

When to Consider This Package

Consider (pilot) when:

• Your test suite is Eloquent-factory-shaped and you want more than Laravel's native factories: dynamic/named states attached to model classes, and attribute expansion that reuses factory definitions instead of duplicating arrays.
• You need dummy-model construction with minimal setup and no full Laravel install — a shared package repo, a CLI tool, or a narrow queue-worker test harness.
• You are running or planning a Laravel 12 → 13 upgrade and want the test-data layer to not be the blocker; both are explicitly supported.
• Your team runs PHPStan/Psalm at a meaningful level in CI and values the generics added in v1.5.1.
• A single-maintainer, MIT, fork-friendly dependency is acceptable risk — and you will pin a minor version and own the exit.

Look elsewhere when:

• You just need fixtures. Laravel's built-in model factories plus fakerphp/faker cover the large majority of needs at zero marginal risk. If current factories read fine, this is a solution in search of a problem.
• You need realistic, domain-valid data (valid IBANs, plausible addresses, locale-aware names). That is Faker's job; this package generates dummy structure, not domain fidelity.
• You need vendor support, an SLA, or a broad knowledge base. Zero dependents means no ecosystem to lean on when something breaks; MIT does not answer an unanswered issue.
• You need API stability over the next 12 months. v2.0.0 is a breaking rename — a healthy conflict-avoidance choice, but it signals the public surface is still settling. Budget a migration or pin a major and accept drift. v2.0.1's filled(...) fix on non-Stringable attributes confirms edge cases are still surfacing in real use.
• You are not on Laravel-adjacent idioms. The value concentrates in HasFactory and Arr helper semantics; on Symfony or vanilla PHP you would reimplement the parts that matter.
• You need GUI/admin-panel data tooling, or anything on the production path. This is dev tooling and should never appear in require.

Adoption criteria required before standardizing: a greenfield or actively-churning test suite; a named dependency owner; a pinned ^2.0.1 constraint with a documented upgrade runbook; a one-sprint spike replacing 2–3 real factories with before/after authoring time and CI wall-clock; and a written exit plan (fork, or revert to native factories — both cheap here).

How to Pitch It (Stakeholders)

For executives: "This is a small, free (MIT) developer-productivity package for generating test data in our PHP/Laravel services. The upside is developer time and a test-data layer that works across our Laravel versions and even outside a full Laravel install. The risk is real but bounded: single maintainer, low public adoption, and a breaking 2.0 release just shipped. Because it's dev-only, MIT-licensed, and does nothing in production, the downside is roughly a day of migration work — not an outage. My recommendation is a one-sprint pilot with a named owner, not a mandated standard. We should not frame this as a strategic investment or attach a savings number we can't measure."

For engineering: "DirectoryTree/Dummy is a require-dev helper for building dummy models and factory-shaped test data. What's actually interesting for us: (1) it decoupled from the Laravel framework in v1.1.0, so it can live in shared packages and narrower services; (2) v2.0.0 namespaced its methods specifically to avoid colliding with other packages — the author is thinking about coexistence; (3) it tracks Laravel majors fast (12 in v1.2.0, 13 in v1.4.0); (4) dynamic HasFactory states (v1.3.0), factory-method parity (v1.5.0), Eloquent attribute expansion (v1.6.0), and generics (v1.5.1) mean it targets real factory ergonomics, not just random strings.

What I want from the spike: replace two or three of our most annoying fixtures, confirm it composes with existing factories rather than replacing them, check PHPStan stays clean, and measure authoring time before and after. Constraints: pin ^2.0.1, keep it out of require, and document the fallback — our native factories — so the exit is a revert, not a rewrite. If the spike doesn't clearly beat native factories plus Faker for our actual fixtures, we walk away and lose nothing but the spike."