Currency Bundle Laravel Package

Product Decisions This Supports

• Market expansion / localization roadmap. Multi-currency display is usually the first gate on entering a new market. This bundle answers a narrow scoping question: can we show localized prices without building an FX layer? If yes, market entry becomes a content/config task rather than an engineering project.
• Build vs. buy (buy vs. borrow). It's a thin, MIT-licensed wrapper: a converter service plus a Twig extension that formats and converts a value. That's roughly 1–2 days of internal work, so the real decision this informs is "do we own this code or take a dependency?" — not "do we need a currency feature?"
• Feature scoping: display-time conversion vs. transactional FX. This package supports presentation (show an approximate price in the user's currency). It does not support settlement (charging in that currency), hedging, or rate guarantees. That distinction should drive whether the feature is a UI ticket or a finance/compliance workstream.
• Rate sourcing and freshness policy. The bundle delegates rate retrieval to an injected provider and caches results, so the PM decision it forces is: which provider, what cache TTL, and how much staleness is acceptable on a product page or checkout preview.
• Concrete use cases: localized catalog browsing, geo-based price display, admin/reporting views in a base currency, and Twig templates that need a price|currency style filter without custom logic in views.
• What it explicitly does not decide: rounding and presentation rules per market, tax-inclusive vs. exclusive display, rate audit trails, or per-market price lists. Those remain product and finance calls regardless of the package.

When to Consider This Package

Adopt (narrowly) when:

• You are maintaining an existing Symfony 2.x application already inside the Lexik/Symfony ecosystem, and adding a dependency is cheaper than writing the converter.
• You already have (or are happy to own) a rate provider — the bundle converts and formats; it does not source rates for you.
• The requirement is display-only, low-stakes conversion with a tolerable cache window (approximate prices, "from" pricing, internal reporting).
• You want a reference implementation for how to structure a converter service + Twig extension + cache, and intend to reimplement it internally.

Look elsewhere when:

• Your stack is Laravel. This is a Symfony bundle with Symfony-specific service wiring and Twig integration; there is no Laravel service provider, Blade directive, or config bridge. It is not adoptable as-is.
• You are on modern Symfony (5/6/7). Symfony 2.x has been end-of-life since 2018, and this package carries 0 dependents and 58 stars — effectively no maintenance signal, no security patch path, and a bus factor of ~1.
• You need money correctness. For anything touching charges, refunds, or accounting, use a dedicated money value-object library plus a real FX provider rather than a string-formatting filter. Floating-point conversion in display code has a habit of leaking into billing code.
• You need historical rates, provider fallback, rate audit trails, or per-market pricing rules. Those are platform concerns this package does not address.
• You need SLAs or vendor support. MIT plus low activity means you are self-supporting from day one.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed utility for showing prices in a user's local currency in legacy Symfony 2 storefronts. It converts and formats — it does not process payments, guarantee rates, or handle tax. Recommendation: do not fund a roadmap around it, and do not treat it as the foundation of a market-expansion strategy. Its value is as a cheap unblock for display-only localization, or as a design reference if we build this ourselves.

To engineering: It's a single converter service plus a Twig extension, provider-agnostic and cache-backed — a small surface area with a clean seam at the rate provider. The catch is that it is Symfony 2-only and effectively unmaintained (58 stars, zero dependents, Symfony 2 EOL since 2018), and it has no Laravel integration. If we touch it at all, wrap it behind our own CurrencyConverter interface so the dependency is swappable, keep it strictly in the presentation layer, and never let its output feed billing or accounting logic. For greenfield work, a money value-object library plus a maintained rate provider is the lower-risk path.