Financial Twig Extension Bundle Laravel Package

Product Decisions This Supports

• Where formatting lives: view layer vs. domain layer. The package bets that currency/number rendering is a template concern. That's an architectural fork worth deciding explicitly — the alternative is a Money value object with its own formatters, which changes how the domain model and API contracts look.
• Build vs. buy for a very small surface. The functional scope (filtering/formatting financial values for display) is typically 20–100 lines of custom Twig code. The real decision is "do we take a dependency for something this small?", and the honest answer here is usually no.
• Build vs. buy for adjacent money concerns. This package does not cover storage precision, currency conversion, allocation/splitting, or parsing user input. If the roadmap includes any of those, the decision shifts to moneyphp/money or brick/money plus a thin formatter, not to this bundle.
• Rounding policy as a product-visible decision. Whether we round half-up or half-even, and at what scale, is something customers notice at the cent level. Shipping a helper without documenting the policy defers a product decision to an implementation detail.
• Roadmap sequencing for invoice/reporting/dashboard work. If the team is on Symfony + Twig, this can unblock "make the numbers display correctly" stories without waiting on a money-domain refactor — useful for a demo or internal tool, less so for a revenue-critical surface.
• Framework fit. This is a Symfony Bundle, not a Laravel package. It assumes Symfony bundle registration and Twig. In a Laravel/Blade context it is not a decision this package can support at all — NumberFormatter, Laravel's Number helpers, or a custom Blade directive cover the same ground natively.

When to Consider This Package

Consider it when:

• The stack is Symfony with Twig already in use, and the need is strictly presentational — taking an already-computed amount and rendering it.
• The work is a leaf-node convenience (an internal admin view, a prototype, a one-off report) where a dependency carries no blast radius.
• You have read the source and pinned the version. It's MIT, so you can vendor or fork it if the maintainer walks away.
• Adoption risk is acceptable: 1 star, 0 dependents, single maintainer organization (Hostnet), last release Feb 2025. That's a dependency you accept only when it can't hurt you.

Look elsewhere when:

• You're on Laravel/Blade. Use NumberFormatter, Laravel's Number/Str helpers, or moneyphp/money with a custom Blade directive. The bundle's registration model doesn't map cleanly even via TwigBridge.
• You need correctness guarantees: arbitrary-precision decimals, currency conversion, parsing user input, allocation, tax math, ledger integrity.
• You need broad locale coverage — PHP's intl NumberFormatter or ICU-backed libraries handle this better and are maintained.
• Your team has any adoption threshold for third-party dependencies. This sits below essentially any reasonable bar, and the cost of replacing it is measured in hours — which cuts both ways: don't adopt it, and don't fear replacing it.
• You need auditable rounding semantics and meaningful test coverage.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed Symfony bundle that adds Twig filters for displaying financial values. It's a formatting convenience, not a money-handling platform. Adoption cost is hours; replacement cost is also hours. It does not de-risk anything material, and it introduces a dependency with effectively zero adoption. Recommendation: don't adopt it as a dependency — replicate the formatting logic internally (it's small) so we own it outright.

For engineering: Treat it as a presentation helper only. It does not solve storage precision, multi-currency, or rounding policy — those stay our responsibility and belong behind a Money abstraction (moneyphp/money) if financial display becomes a broader concern. If we do use it, wrap it behind our own Twig extension interface so templates never couple to the vendor, and pin the version.

Note on applicability: the package is a Symfony Bundle, so this assessment applies only if we are on Symfony/Twig. In our Laravel/Blade context it's a non-starter — we'd implement the equivalent as a Blade directive in well under a day.