- Can I use syno/money-bundle in a Laravel application?
- No. syno/money-bundle is a Symfony bundle, and Laravel has no bundle or kernel-extension mechanism, so the package as shipped cannot be dropped into a Laravel app. Its only job is registering moneyphp/money services and configuration inside Symfony's DI container, which Laravel does not provide. Treat it as reference material and adopt the underlying library instead.
- What does syno/money-bundle actually provide beyond moneyphp/money?
- Very little. Its documented scope is narrow: it wires the mathiasverraes/money library (now moneyphp/money) into Symfony's container and exposes configuration. All of the real value, meaning immutable monetary value objects, currency-aware arithmetic, and Fowler Money pattern semantics, lives in the underlying library, which is mature and widely used. The bundle is thin glue, so replacing it means writing roughly a 100-line service provider you own.
- How should I handle money in Laravel without floating-point errors?
- Add moneyphp/money as a first-class Composer dependency and inject Money value objects rather than passing floats or strings around. Store amounts as integer subunits in the database and only format at the edges of your application. Use the library's currency-aware arithmetic for totals, allocation, and conversions so rounding is explicit instead of accidental.
- Is syno/money-bundle still maintained?
- The evidence points to no. The last release was 2022-03-28, the repository has zero stars and zero dependents, and there is no visible issue triage, stated support window, or security advisory history. It is a single-maintainer, low-traffic project that could be archived without notice. Adding an unmaintained node to your Composer graph is a standing upgrade blocker and an audit finding.
- What PHP and Symfony version constraints does syno/money-bundle declare?
- A bundle last released in early 2022 is likely pinned to Symfony 4/5-era APIs and PHP 8.0 or lower, which conflicts with current Laravel and PHP 8.2 and newer stacks. You must read its composer.json constraints before considering it at all, because a stale pin will either block the install outright or lock transitive packages you want to upgrade. Check whether it also pins a moneyphp/money version you would otherwise want to move independently.
- How do I configure a default currency and rounding mode in Laravel without this bundle?
- Create a config/money.php file holding the default currency, subunit precision, and default rounding mode, mirroring the settings the bundle would have exposed. Bind a MoneyFactory or CurrencyRegistry as a singleton in your own MoneyServiceProvider, then inject it instead of calling new Money inside controllers. Keep those defaults in config rather than hard-coded so currency and rounding do not silently become business rules buried in code.
- Which calculator backend does moneyphp/money need and does it matter for deployment?
- moneyphp/money can use bcmath, gmp, or a pure PHP calculator, and the choice affects performance and precision guarantees. Confirm the required extension is present in CI and in every production image, since a missing extension surfaces at runtime rather than at install time. Pin the calculator explicitly in configuration so environments do not silently diverge.
- How do I test money handling in a Laravel application?
- Pin moneyphp/money to a known-good minor and run the full test suite against it before merging. Assert currency equality alongside amounts, cover remainder allocation and rounding boundaries, and add cases that would fail if a float ever enters the pipeline. Also check transitive conflicts around serializer and intl during the upgrade.
- What are the alternatives to syno/money-bundle for Laravel?
- The strongest option is moneyphp/money used directly with your own service provider, which keeps you on a maintained library and removes a dead dependency. brick/money is a viable alternative with similar immutable value object semantics. Framework-specific wrappers exist but add the same kind of thin glue you can write and own in an afternoon.
- What is the migration and exit plan if we adopt money handling this way?
- Assume greenfield: add moneyphp/money to composer.json, create config/money.php, bind a MoneyFactory singleton in a service provider, and replace any container IDs from bundle-derived code with explicit bindings. Because there are effectively no dependents, there are no downstream users to coordinate with. Record the decision as a short ADR citing syno/money-bundle as reference material and naming an internal owner.