Weave Code
Financial Twig Extension Bundle Laravel Package
hostnet/financial-twig-extension-bundle
Hostnet Financial Twig Extension Bundle adds Twig filters and functions for financial calculations and formatting, helping Symfony templates handle values like VAT, interest, and currency display without extra PHP logic. Simple to install and integrate.
Hostnet Financial Twig Extension Bundle integrates financial helpers directly into Twig templates for Symfony applications. It provides reusable filters and functions for presenting and manipulating monetary values, helping keep formatting and basic financial logic out of controllers and templates.
- Money-aware Twig filters for consistent currency and amount output
- Locale-friendly formatting for displaying financial values
- Reusable financial functions to simplify common template calculations
- Symfony bundle integration with straightforward extension registration
- Cleaner templates by centralizing financial presentation logic
Frequently asked questions about Financial Twig Extension Bundle
- Can I use hostnet/financial-twig-extension-bundle in a Laravel application?
- Not as a bundle. It is a Symfony Bundle that ships a Bundle subclass, a DI Extension, services.yaml resource loading and twig.extension service tagging, none of which Laravel understands, so the wiring is silently ignored. The reusable part is the Twig extension layer: AbstractExtension classes with filters and functions are framework-agnostic and run anywhere Twig runs. You would register those manually or port the filter bodies into your own code.
- Does this package work with Blade templates?
- No. The package exposes Twig filters and functions, and Laravel ships Blade by default, so there is no natural consumer for them. Your options are porting the formatting logic into a service plus Blade directives such as @money or @percent, or introducing rcrowe/twigbridge in a bounded rendering context like PDF statements or financial emails. For a Blade-first app only the formatting logic transfers and the Symfony packaging is pure overhead.
- How do I install hostnet/financial-twig-extension-bundle?
- In Symfony it is a standard Composer install via composer require hostnet/financial-twig-extension-bundle, followed by enabling the bundle in config/bundles.php so the DI extension can tag the Twig extensions. In Laravel there is no bundle registration step and Composer will not wire anything automatically. You would install it only to reuse the extension classes, which you then register yourself.
- Which Laravel and PHP versions does this bundle support?
- There is no official Laravel support matrix. The bundle's CI targets Symfony and PHP versions, not Laravel, so any guarantee on Laravel 10, 11 or 12 with PHP 8.2 to 8.4 is yours to verify. Check the composer.json constraints for PHP, twig/twig and symfony/* before assuming a clean install, since Twig and Symfony constraints are the usual source of conflicts.
- How do I register these Twig extensions manually in Laravel?
- Install rcrowe/twigbridge, then in a service provider's boot method resolve the Twig environment and call addExtension for each extension class. Because the bundle's twig.extension tags are ignored, you must instantiate each extension yourself, which means checking its constructor for Symfony service or config dependencies. If the classes take locale providers or formatter config objects, build those manually or the extensions will not instantiate.
- What filters and functions does the bundle actually provide?
- The overview describes filters and functions for rendering currencies, monetary amounts and financial values cleanly, but it does not enumerate them. Before committing, read the extension classes to see whether the surface is two filters or twenty, and whether it covers currency symbols, percentages, sign display and K/M/B abbreviation. That inventory determines how much work a port really is.
- Does it depend on moneyphp/money, brick/money or just number_format?
- The package description does not say, so inspect composer.json and the extension constructors. If it relies on a money value object the port is significantly larger because you must carry that dependency or reimplement its semantics. If it is a thin wrapper around number_format or NumberFormatter, extracting the filter bodies is quick.
- Is ext-intl or ICU a hard requirement?
- Unconfirmed from the available description, but it matters for your Docker images and CI. If the extensions delegate to NumberFormatter, ext-intl and a suitable ICU version become hard requirements and output can vary between environments. Check the extension code and composer.json, then pin the extension in your runtime image if you adopt it.
- How does its output compare to Laravel's Number::currency() helper?
- Laravel already provides Number::currency and Number::percentage helpers backed by ICU, so there is overlap before you add any dependency. Financial display semantics are audit-visible: rounding mode, negative representation such as -1,234.00 versus (1,234.00), and grouping separators all matter. Build a small fixture suite covering those cases and compare both implementations before deciding to port or adopt.
- Is this package actively maintained and safe for production?
- Adoption signals are weak: roughly one star, zero dependents and a composite score of 0.125, meaning effectively no external battle-testing and no downstream canary for breakage. Upstream is a single agency organization rather than an individual, and the MIT license removes legal friction, with a recent 2025-02-11 release as the main positive maturity datapoint. For production financial output, plan on writing your own tests and characterizing behavior rather than trusting upstream guarantees.
Weaver
How can I help you explore Laravel packages today?