Referential Bundle Laravel Package

Product Decisions This Supports

• Reference-data strategy: code vs. data. The core decision a "referential" layer forces is whether lookup lists (countries, currencies, categories, risk profiles, fee schedules, regulatory classifications) live as enums/config in code or as DB-backed tables with an admin surface. This package is a worked example of the second path — it registers services, container parameters, and Doctrine mappings so controlled vocabularies are configured once and injected consistently. That is the pattern to evaluate against, whether or not you adopt the code.

• Build vs. buy vs. borrow. With 0 stars, 0 dependents, and a score of 0, this is not a "buy." The real decision it supports is borrow: read the data model and conventions, then either vendor/fork or reimplement in-house. Frame the output of the evaluation as an internal design document, not a dependency addition.

• Framework fit as a gating decision. Despite the Laravel framing, the -bundle suffix and vendor namespace indicate this is a Symfony bundle — Symfony kernel, DI container, service tags, and almost certainly Doctrine ORM. For a Laravel shop this is a domain-model reference, not an installable package; that constraint should be surfaced before anyone adds it to a backlog ticket. For a Symfony shop it is at least architecturally conventional.

• Roadmap input for internal tooling. If the backlog contains "let non-engineers edit the country list / taxonomy / fee schedule without a deploy," a referential component is the enabler. This package is a cheap data point on how a peer fintech (Mon Petit Placement) modeled that problem — useful for scoping, estimating, and writing acceptance criteria even if the code is never used.

• Compliance and audit scope. Fintech-adjacent reference data usually carries requirements around who changed which value, when, and why. Evaluating this bundle forces the question early: does our reference data need versioning, approval workflows, and change history? Cheap to design in now, expensive to retrofit.

• API/versioning hygiene. Whether your application code references stable codes/slugs or raw database IDs is a product-level decision with long-tail consequences (exports, integrations, partner APIs). The package's conventions are a prompt to standardize on stable codes.

When to Consider This Package

Worth reading (as a reference, not a dependency) when:

• You are on Symfony, not Laravel — the architecture will actually map.
• You have many small reference tables (roughly 10+) and are tired of hand-rolling CRUD and choice loaders for each.
• The use case is internal, low-blast-radius, and you are prepared to vendor or fork and own maintenance.
• Someone on the team can read source directly. Assume no README depth, no changelog, no support, no issue history.

Look elsewhere, or build in-house, when:

• Adoption signals matter to you — and here they are all zero. Zero stars, zero dependents, zero score means no community validation, no external bug reports, no pressure to keep the API stable, and no visible security-response process. Treat as abandoned-by-default until proven otherwise.
• You need an SLA or support contract. None exists.
• You are on Laravel. Do not attempt to install it. Use native options instead: backed enums, config-driven lists, or a lookup table plus an admin panel (Filament/Nova) pattern. This category is well served by first-party framework features.
• The data is business-critical — pricing, eligibility, compliance, PII-adjacent classification. Critical data deserves a maintained dependency or an owned internal module, not a zero-adoption bundle.
• You require audit trails, label i18n, approval workflows, or import pipelines. Verify in source before assuming; smaller extractions typically omit these.
• No license file, no tagged releases, or no commits in the last 12 months. Any of these should end the evaluation.

How to Pitch It (Stakeholders)

For executives: This is a small, single-company Symfony bundle for managing reference data — the lookup lists behind dropdowns and business rules. It has no adoption: zero stars, zero dependents, no releases cadence, no support. It is not a dependency we should take on. It is, however, a near-zero-cost window into how a peer fintech solved a problem we will face as soon as non-engineers want to edit a taxonomy without a deploy. Recommendation: spend a few engineering hours reading the data model and conventions, produce a one-page build-vs-borrow recommendation, and move on. The cost of the evaluation is trivial; the cost of adopting it uncritically is an unmaintained dependency we would silently own.

For engineering: Treat mpp/referential-bundle as a reference implementation, not a library. It is Symfony-flavored, undocumented by any measurable signal, and unmaintained upstream. Concretely:

• Day 1 — provenance audit: license compatibility, last commit date, tagged releases, CI status, and the real dependency tree (composer show --tree in a throwaway project). Confirm the PHP and Symfony version constraints before anything else.
• Days 2–3 — spike (Symfony only): register the bundle, import its service config, run migrations, and exercise the read/write paths. Audit src/DependencyInjection/ for globally registered services or event subscribers that could alter behavior outside the bundle's namespace — internal extractions often do this.
• Decision gate: adopt-as-dependency (Symfony only), fork-and-own at a pinned commit SHA, or harvest-the-design-and-reimplement.
• Non-negotiable either way: put your domain behind an anti-corruption layer. Your code should depend on our referential interface, not the bundle's classes, so a swap later is a contained change.
• Do not add it to composer.json for anything touching money, eligibility, PII, or compliance.

If we decide we genuinely want a referential layer, propose it as an internal module with a named owner, a changelog, audit logging, and a data-freshness process — the things this package almost certainly does not ship. Watch for two known failure modes: French-locale reference data and validation baked into a nominally "generic" model, and uncached findAll-style reads that become N+1s in a hot path.