Core Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for commerce primitives. Elcodi decomposes cart, order, checkout, pricing, currency and tax into discrete Symfony components and bundles. Reading that decomposition is a cheap way to scope how much of a commerce domain we build ourselves versus assemble from libraries — even though we would not install it.
• Domain model review before schema commitment. The cart/order/product abstractions and their state transitions are useful reference material. A few hours of reading can pressure-test our own entity boundaries and lifecycle design before we lock a database schema.
• Platform strategy — Laravel-first vs. Symfony-tolerant. This package forces the question explicitly. It is a Symfony bundle (kernel, DI container extension, compiler passes), not a framework-agnostic PHP library. Evaluating it is really a decision about whether our stack tolerates Symfony idioms; the answer affects hiring, hosting and every future library choice.
• OSS adoption bar and dependency risk policy. Zero stars, zero dependents, read-only distribution, no PR acceptance, dormant community channels — a clean case study for defining our minimum bar (maintained upstream, active dependents, documented security response path, named owner).
• Explicitly not supported: any "adopt this as a dependency" decision. It does not support a buy, adopt, or ship recommendation. It supports informing a decision, not making one.

When to Consider This Package

Consider it only when all of the following hold:

• We are already on Symfony and already inside the Elcodi ecosystem — this repo is a read-only subtree split of elcodi/elcodi, so upstream is the only real entry point for issues and fixes.
• We are maintaining a legacy Elcodi installation and need to understand, pin, or patch an existing bundle rather than introduce a new one.
• We want read-only reference material: a worked example of commerce domain modelling to copy as patterns, not code.
• We have accepted that we own all maintenance, security patching and future PHP/framework upgrades ourselves, and have named an owner for that obligation.

Look elsewhere when:

• We are building anything new, or running Laravel. The bundle expects a Symfony kernel and Doctrine entities; a Laravel ServiceProvider cannot wire it the way Symfony does. Framework mismatch alone disqualifies it.
• We need a maintained dependency: active releases, a CVE path, responsive maintainers, or a talent pool to hire from. Symfony 2-era bundle conventions are increasingly rare and Elcodi-specific knowledge is effectively zero.
• We need production support or SLAs, or a vendor who will accept fixes — this repo accepts no PRs by design.
• We need commerce capability we can buy. A hosted commerce platform or an actively maintained Laravel-native package will beat assembling an unmaintained Symfony suite.
• We are weighing adoption signal. Note the caveat: the 0 stars / 0 dependents / "readme" maturity scores are artifacts of the subtree split, not evidence about the parent project. Treat them as uninformative, not as proof of unpopularity — and still do not adopt, because the integration risk is independent of the star count.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Use as a design reference only.

elcodi/core-bundle is the foundational bundle of the Elcodi e-commerce suite — MIT licensed, free to use, and structurally incompatible with a Laravel codebase. It distributes as a Symfony bundle wired into the kernel and DI container, not as a reusable PHP library. Its public presence is dormant, it is a read-only subtree split that accepts no pull requests, and there is no upstream to escalate to.

For executives. This is a no-cost but high-risk option. The licence is free; the total cost of ownership is not. Adopting it means we inherit unmaintained PHP 5.x-era code against a PHP 8.1+ target, absorb all security patching and framework upgrades, and become the maintainers of a library nobody else depends on. That is a permanent fork owner we would have to hire for — and there is essentially no talent pool with Elcodi experience. Expect Composer dependency resolution to fail outright before we even reach the interesting risks.

For engineering. Treat the repository as documentation. It is worth a timeboxed read of the CoreBundle service definitions and its sibling components to enumerate the domain concepts — currency and locale context, pricing and tax rules, cart/order lifecycle hooks, entity event wiring — then re-express those concepts natively in Laravel (app/Domain value objects, Eloquent repositories, Laravel events mapped one-for-one to Elcodi's event names). That preserves the genuinely valuable part, the domain knowledge, and discards the Symfony coupling that makes it uninstallable. Run a one-to-two-day spike to make the rejection evidence-based; do not attempt --ignore-platform-reqs to force it through.

The ask. Approve closing this evaluation as "reference only," record the finding so it is not re-litigated, and let us set a minimum OSS adoption bar — maintained upstream, active dependents, documented security response path, named internal owner — so future evaluations resolve faster. If we want commerce capability, the real fork in the road is (a) a maintained Laravel-native package, (b) a hosted platform, or (c) building the narrow slice we need in-house. That is the decision worth spending committee time on; this package is not.