- Can I use moneyphp/money-bundle in a Laravel application?
- No. The package is a Symfony bundle built on Symfony DI, Twig, Form and Validator, so its service definitions and Twig extension will not load in Laravel. In a Laravel or framework-agnostic app, install moneyphp/money directly and register the formatter and parser in a small service provider. The bundle's value collapses to the underlying library plus glue code you would otherwise write yourself.
- How do I install and enable moneyphp/money-bundle?
- Install it with composer require moneyphp/money-bundle, register the bundle in config/bundles.php, then configure your default currency and decimal places in the bundle configuration. Formatter and parser services become available for autowiring, and the Twig extension, form type and validator are registered automatically.
- Which Symfony and PHP versions does moneyphp/money-bundle 0.1.0 support?
- The v0.1.0 release notes do not state supported Symfony or PHP versions, so inspect the composer.json constraints in the tagged release before adopting. Symfony 6/7 and PHP 8.2/8.3 compatibility is the main unresolved technical risk. Test it with a composer require on a throwaway branch before committing to the upgrade path.
- Is moneyphp/money-bundle 0.1.0 safe to use in production?
- It is pre-1.0, so semver permits breaking changes in any minor release and the API should not be treated as stable. The blast radius is limited: the surface is small, it is MIT licensed, and it is forkable or replaceable with a handful of service definitions. If you need stability, depend on moneyphp/money directly and skip the bundle.
- Is moneyphp/money-bundle abandoned or still maintained?
- A 0.1.0 release exists, so the older framing of a package frozen in 2020 is no longer accurate. However, the version is labelled first release, which could mean a relaunch, a fork re-versioned under the same name, or a history reset, and none of that is confirmed. Which lineage you are tracking matters for planning the next major Symfony upgrade.
- How do I format monetary values in Twig with moneyphp/money-bundle?
- The bundle registers a Twig extension backed by formatter and parser services defined in the container. Configure the default currency and decimal places, then pass Money value objects to the extension in your templates. Output correctness relies on ext-intl and its CLDR data, which drift between PHP releases.
- How do I validate a currency code in a Symfony form?
- Use the bundle's form type and validator together with the DI-provided ISO currency service added in v0.1.0. That service gives forms and validators a single source of currency metadata, useful for picklists, validating submitted currency codes, and admin configuration screens. Without it, teams typically duplicate that list in three places.
- What is the difference between moneyphp/money and moneyphp/money-bundle?
- moneyphp/money is the value object library; the bundle is a thin Symfony integration layer adding a bundle class, DI service definitions for formatters and parsers, a Twig extension, a form type and a validator. You can install the library alone and wire those pieces yourself. The bundle earns its place only in a Symfony app where money flows through DI, Twig and forms.
- How do I migrate from moneyphp/money-bundle to plain moneyphp/money?
- Keep moneyphp/money and model amounts as Money with explicit currencies; that is the durable decision regardless of the bundle. Replace the bundle with a few service definitions in your own config, or an equivalent service provider outside Symfony, for the formatter and parser. Then remove or port any Twig extension, form type and validator usages.
- How do I build a currency picklist in Symfony without hardcoding ISO 4217 codes?
- v0.1.0 adds a service definition of ISO currencies, giving you a container-provided currency registry to inject into a ChoiceType or a validator. That removes the recurring chore of hand-maintaining a 4217 array or calling Money::getCurrencies() yourself. Confirm whether the list is static or derived at build time, and who refreshes it when ISO 4217 changes, since it can drift independently of ext-intl data.