- Does padam87/money-bundle work with Laravel?
- No. It is a Symfony bundle built on a DI extension, Doctrine DBAL types, Twig filters, and form types, with no Laravel service provider, facade, Eloquent cast, or Blade directive. Laravel teams should install moneyphp/money directly and write a small cast, directive, and validation rule. That is roughly one to two engineer-days of work.
- How do I install padam87/money-bundle in a Symfony application?
- Run composer require padam87/money-bundle, register the bundle in config/bundles.php, configure your default and service currencies, and annotate entity columns with the bundle's DBAL type. Confirm the tagged version constraints against your PHP version, Symfony major, and doctrine/dbal major before committing.
- Which Symfony and doctrine/dbal versions does padam87/money-bundle support?
- The tagged constraint set must be verified independently because the overview does not state supported majors. DBAL 3.x and 4.x type APIs differ, so check the type class signature against your installed dbal. Also check whether there is a CI matrix rather than a single passing badge on one PHP version.
- Does the Doctrine DBAL type store money as integer minor units or decimal strings?
- The overview does not specify the storage representation, which matters for lossless round-trips. Inspect the type's convertToDatabaseValue and convertToPHPValue methods before committing. Test negative amounts, null values, and zero-decimal currencies to confirm behavior.
- How does padam87/money-bundle handle currency storage — per-row currency column or a single configured currency?
- This is not documented in the overview. The bundle registers currency configuration through its DI extension, so you can set default and service currencies, but whether each row stores its own currency code depends on the DBAL type implementation. Verify this against your schema before designing a migration.
- Does the bundle format zero-decimal currencies like JPY and high-precision currencies?
- This is not confirmed. The Twig filter formatting layer's handling of zero-decimal and eight-decimal currencies must be tested explicitly. Do not assume it is correct just because it works for EUR or USD.
- What rounding mode and allocation strategy does padam87/money-bundle use?
- The bundle is a thin layer over moneyphp/money, so rounding and allocation behavior largely come from the underlying library. Whether the bundle bakes in a default rounding mode or allows per-context overrides is not stated and must be verified. Rounding policy is the most incident-prone part of money handling, so test it in isolation.
- Is padam87/money-bundle production-ready and actively maintained?
- Treat the risk as high relative to the value delivered: four GitHub stars, zero dependents, a single maintainer, and no documented security disclosure process. The stated last release of 2026-03-11 should be treated as unverified supply-chain metadata until you confirm a signed tag, a Packagist artifact, and a changelog. Assume you own the code if you adopt it.
- What is the best alternative to padam87/money-bundle for a Laravel app?
- Use moneyphp/money directly. Implement an Eloquent cast such as AsMoney that stores integer minor units in a BIGINT column, add a Blade directive for locale-aware formatting, and add a validation rule. Pin moneyphp/money to a known major and record the constraint in composer.json.
- How do I migrate existing DECIMAL or float money columns to moneyphp/money safely?
- Read the legacy columns, convert with an explicit rounding mode, write integer minor units, and keep the legacy column readable during a dual-read window. Dual-write for one release cycle, reconcile nightly with a diff job that fails loudly on mismatch, then cut over reads and drop the legacy column. Do not let formatting and business rules land in the same pull request.