Lendo Fixtures Bundle Laravel Package

Technical Evaluation

Architecture fit. The package name ends in bundle, and the vendor namespace (lendo-stp-gdansk) points to an internal Straight-Through-Processing group at Lendo (Gdańsk). "Bundle" is Symfony vocabulary, not Laravel. Laravel's extension surface is the service provider, facade, and artisan command triad; Symfony bundles are a distinct kernel-level registration model. Before anything else we must establish whether this is (a) a Symfony bundle that happens to be installable in a Laravel app, (b) a Laravel package misnamed by convention, or (c) framework-agnostic PHP wrapped in a Symfony bundle shell. Only (b) and partially (c) are viable for us. There is a real chance the package is Doctrine-coupled (Doctrine Data Fixtures / Alice-style loaders), which would make it structurally incompatible with Eloquent and our migration tooling.

Integration feasibility. The package is not on a public registry footprint we can validate — zero stars, zero dependents, a score of 0. That is not a quality signal; it is an absence of signal. Realistically this is an internal package consumed through a private Composer repository or VCS path repository, meaning integration is gated on credentials, CI secrets, and a supply-chain review rather than on technical merit. Feasibility therefore hinges on access, not on code: we cannot size the work until we can read the composer.json constraints (PHP version, Laravel/Symfony version, required extensions) and the fixture engine's public API.

Technical risk.

• Ecosystem mismatch (high): Symfony bundle semantics against a Laravel codebase. Console commands may be Symfony Console-based and only partially bridgeable through Illuminate\Console.
• ORM coupling (high): A fixture engine's value is its data-layer integration. If it targets Doctrine, it is a non-starter without an adapter, and an adapter may cost more than a native Laravel seeder implementation.
• Blast radius (high): Fixture/seed tooling writes to databases. Misconfiguration can seed a shared or production-adjacent environment with synthetic-but-realistic records, including the possibility of PII-shaped data.
• Bus factor (high): Internal single-org package with no public issue traffic implies one or two maintainers and no external validation.
• Longevity (medium): No dependents means no community pressure to keep it current with new PHP/Laravel majors.

Key questions.

1. Is this a Symfony bundle, a Laravel package, or framework-agnostic? What does composer.json declare under require and type?
2. Which ORM/data layer does the fixtures engine target — Doctrine, Eloquent, raw PDO, or a driver abstraction?
3. How is the package distributed (Packagist, private Satis/Toran, git submodule, path repo)? What is the authentication story?
4. What is the supported PHP/Laravel version matrix, and who commits to updating it?
5. What is the actual capability delta versus Laravel factories + seeders + Faker — is it a DSL, a dependency graph resolver, a scenario library, or all three?
6. Is there a determinism/seed guarantee (reproducible fixtures) and a documented idempotency/truncation model?
7. Who supports it, through what channel, and what is the documented SLA for our team?
8. Does it contain or reference customer-derived data schemas that carry compliance obligations (GDPR) if reused outside Lendo's own services?

Integration Approach

Stack fit. Treat this as unproven until a spike proves otherwise. Our presumed target is Laravel with Eloquent and Pest/PHPUnit. Laravel already ships a fixtures engine in all but name: model factories, DatabaseSeeder, RefreshDatabase, and Faker. Any adoption decision must be framed as "what does this bundle give us that factories do not?" — the likely answer is a declarative scenario DSL and cross-project fixture sharing, which is genuinely valuable for parity between services, but only if the data layer bridges cleanly.

Migration path. There is no migration to perform — we are adopting, not replacing. The correct path is:

1. Access and audit. Obtain repository read access, pin a specific tag/commit, review composer constraints, license, and any transitive dependencies. Record an SBOM entry.
2. Static read. Confirm framework target, ORM coupling, and command registration model. This is a 1–2 day effort and can kill the initiative early.
3. Sandbox POC. Install in a throwaway Laravel app against SQLite and MySQL. Attempt to load one fixture set and run one command. Success criterion: data lands, constraints hold, command is reachable from artisan.
4. Adapter layer (conditional). If commands are Symfony Console-native, wrap them as thin Illuminate\Console\Command subclasses; if the data layer is Doctrine-shaped, implement a driver/adapter behind an interface we own so we can swap out later. Keep the adapter in our repository, not a fork, so upgrades are not blocked on us.
5. Pilot. Enable in exactly one non-production service for one sprint, used by engineers who write fixtures weekly.

Compatibility. Pin explicitly ("lendo-stp-gdansk/lendo-fixtures-bundle": "x.y.*"), never a branch alias, and never dev-main. Add a CI job that installs the pinned version and boots the fixture engine so a transitive PHP or Laravel upgrade fails fast in CI rather than in a developer's environment. Verify no global helper/function collisions and no hard-coded service names or table prefixes.

Sequencing. Audit → POC → adapter → pilot → standardization is strictly serial; do not parallelize the pilot with the adapter work, because the pilot's value is measuring the adapter's ergonomics. Insert an explicit kill gate after step 2 and a second one after step 3. If the package is Doctrine-bound and the adapter exceeds roughly 8–10 engineering days, the fallback is to keep the concepts (fixture scenario definitions) and reimplement the loader natively on Laravel factories — we lose cross-project parity, which is a product cost, but we avoid a permanent compatibility tax.

Decision framing for stakeholders. Two credible outcomes: (a) adopt as a shared fixture standard across Lendo-adjacent services, gaining parity and reduced duplicate seeding code; or (b) decline and publish our own thin convention on top of factories. Option (a) is only correct if the ORM bridge is clean and a named maintainer commits to Laravel version support. "Zero dependents" is not disqualifying for an internal package, but it does mean we become a dependent with no crowd to hide behind.

Operational Impact

Maintenance. We inherit the upgrade cadence of an internal team we do not control. There is no public release history to infer velocity from, so we must ask directly and treat a vague answer as a red flag. Mitigations: pin hard, keep the adapter in our repo, and budget a recurring line item (roughly 2–4 engineer-days per Laravel major) for compatibility work we cannot do ourselves. If the package ships from a monorepo, expect releases to be coupled to unrelated Lendo services' schedules.

Support. Support is almost certainly a Slack channel and a person's name rather than a documented process. That is acceptable for developer tooling but must be made explicit in the adoption record: name the maintainer, name the escalation path, and set an internal owner (a single engineer, not a team) so questions have a first hop. Absent that, the package will quietly rot in the dependency list.

Scaling. Fixture runs are I/O- and transaction-bound, not request-bound. Expect cost in three places: (1) database write volume on shared non-production environments — a fixture engine that truncates and reloads will contend with other tenants; (2) CI time, since fixture loading often dominates integration test suites; (3) data volume drift if fixtures are not pruned. Enforce environment guards — refuse to run when APP_ENV=production — and require an explicit allowlist of permitted databases. Consider running fixtures only against per-PR ephemeral databases rather than a shared staging cluster.

Failure modes.

• Partial seed: engine dies mid-load, leaving referentially inconsistent data. Need a documented transaction/truncate model and a verification step.
• Non-idempotent reruns: duplicate rows on repeated execution, poisoning test assertions. Require idempotency before pilot sign-off.
• Schema drift: fixtures written against an older schema silently fail or write wrong columns after a migration. Pair fixture loads with a migration-completeness check in CI.
• Environment misdirection: the highest-severity failure — fixtures pointed at a shared or production database. Guard in code, not in documentation.
• Upstream breakage: a transitive dependency bump in the Lendo monorepo breaks our install with no changelog. Mitigated by pinning plus a boot-smoke CI job.
• Abandonment: maintainer leaves; package goes stale against PHP/Laravel majors. The adapter boundary is the exit ramp — verify we can uninstall and revert to native factories in under a week.

Ramp-up. Expect half a day of onboarding per engineer for a declarative fixture DSL, plus a written internal guide and one worked example in our own codebase. The real ramp-up cost is conceptual, not syntactic: engineers must understand when the bundle's scenarios are preferable to a model factory inline in a test. Publish that boundary explicitly, or engineers will use both patterns inconsistently and we will end up maintaining two fixture idioms. Budget roughly one engineer-week end-to-end for audit, POC, adapter, documentation, and pilot — contingent on the framework question resolving favorably.