- Is merk/dough a Laravel package?
- No. The technical assessment describes merk/dough as a framework-agnostic immutable Money value object, a port of Kent Beck's TDD-by-Example implementation, with no service provider, config file, facade, or built-in Eloquent integration. Laravel can consume it through Composer like any PHP library, but your application must provide the persistence, JSON, queue, and Blade formatting adapters.
- How do I install merk/dough in a Laravel project?
- Mechanically, installation is composer require merk/dough plus PSR-4 autoloading. The real issue is compatibility: the last release is dated 2016-01-18, so its composer.json likely pins old PHP and PHPUnit constraints that may not resolve against modern Laravel applications. Do not use --ignore-platform-reqs in CI as a workaround; fork the source into an internal package and update the constraints if Composer fails.
- Does merk/dough work with Laravel 10, Laravel 11, and PHP 8.1+?
- Compatibility is unproven until you run a spike. The 2016 release predates PHP 7.1 and will likely conflict with Laravel 9, 10, or 11 requirements on PHP 8.1+, so Composer resolution failures are expected. Verify installation on your exact PHP version, run the upstream test suite under PHP 8.x, and vendor the code internally if it fails.
- Does merk/dough provide Eloquent casts and Blade directives?
- The package blurb mentions Eloquent casts and Blade directives, but the technical evaluation found no service provider, config file, facade, or Eloquent integration. Treat those Laravel-specific features as unverified until you inspect the actual source and tests. In practice, plan to write explicit casts, serializers, and Blade formatting helpers yourself.
- How does merk/dough compare to moneyphp/money and brick/money?
- merk/dough overlaps almost entirely with moneyphp/money, the de facto PHP standard, and brick/money, both of which have materially larger feature surfaces. Those alternatives include broader support for allocation, rounding modes, currency repositories, parsers, and formatters. If you adopt Dough, calculate your exit cost to one of those libraries before committing.
- Is merk/dough safe and maintained enough for production?
- Technical risk is high and asymmetric: there has been no release in more than eight years, the project has about 21 stars, it is effectively single-maintainer, and the repository is listed as unknown, so upstream activity cannot be verified. The one genuine advantage is a negligible security attack surface because it is pure computation with no I/O or untrusted deserialization. For production money handling, expect a long-lived maintenance liability unless you fork and own it.
- How does merk/dough handle rounding, allocation, and currency mismatches?
- Kent Beck's implementation is pedagogically clean but was not hardened for FX conversion, proportional allocation, banker's rounding, or jurisdiction-specific tax rounding. The assessment flags currency representation, rounding policy, overflow behavior, and mismatched-currency behavior as unverified. Add tests for every arithmetic and comparison path your product depends on before relying on it.
- How are monetary amounts stored in merk/dough?
- Dough uses integer minor units rather than floats, which avoids floating-point cent loss for exact arithmetic. However, the assessment does not confirm whether amounts use native integers or arbitrary-precision values, so overflow risk on 32-bit systems and very large 64-bit values must be tested. Confirm the backing type and document limits before storing prices or totals.
- Can merk/dough be serialized across Laravel queues and Octane workers?
- Queue and Octane safety are not verified by the available information. You should run serialize and unserialize tests plus a full Eloquent-to-queue-to-worker cycle, and check JSON serialization contracts used by APIs or job payloads. If the serialization format is unstable, wrap it in your own DTO rather than passing Money objects directly across boundaries.
- What should I do if merk/dough conflicts with my Laravel Composer constraints?
- Do not patch files inside vendor or bypass platform checks in CI. The practical path is to fork the source into an internal namespace, update the PHP and dev-dependency constraints, and run the upstream test suite on PHP 8.x. Also add round-trip serialization and overflow tests so the fork is proven against your Laravel version before adoption.