Getting Started

Install with composer require tourze/product-limit-rule-bundle:^1.0. The bundle suffix is a strong hint that this is a Symfony-style bundle; check composer.json for symfony/* requirements before assuming native Laravel support. If it is Symfony-oriented, register it through a small Laravel service provider/bridge rather than expecting package discovery.
Look first at:
- README.md for the rule model and config keys.
- src/ for the rule contract (typically something like RuleInterface), concrete product-limit rule classes, and any Doctrine entities/repositories.
- The bundle's DI extension/config tree if present — that tells you what is configurable vs. what must be coded.
First use case: enforce a per-product purchase limit (e.g. “max 5 units of SKU X per order/customer”) and surface a validation error at add-to-cart and again at checkout. Start with a single hard-coded rule, verify it blocks correctly, then move rules into configuration/database.

Implementation Patterns

Rule registration: instantiate or resolve rules through the container, tag/collect them, and evaluate them through a single limiter service. Keep a thin application-level service (e.g. ProductLimitService) that wraps the bundle so your domain code does not depend on bundle internals.
Data-driven rules: store limits (product/SKU, channel, customer group, min/max quantity, date window) in a table and hydrate rule objects from it. Cache the compiled rule set per product/channel and invalidate on rule writes.
Cart/checkout integration: evaluate limits as a Laravel validation rule on add-to-cart requests, and re-run the full rule set in an order-placement listener. Never rely only on the UI-level check.
Aggregation: sum quantities across cart lines that resolve to the same product/variant before evaluating; the bundle likely evaluates one rule against one subject, so aggregation is your responsibility.
Violation handling: have rules return structured violations (code, message, limit, actual) instead of throwing, then map them to ValidationException messages or API error payloads.
Testing: use factories to create rules and carts; assert both pass and fail paths, including multiple overlapping rules and guest vs. authenticated customers.

Framework mismatch: despite being listed as a PHP package, the bundle naming and Tourze's catalogue suggest Symfony conventions (DI extensions, Doctrine). Budget time for a bridge; don't assume php artisan vendor:publish exists.
Empty 1.0.1 changelog: the release only links a diff. Treat it as a patch release, pin an exact version (1.0.1), review compare/1.0.0...1.0.1 yourself, and run your limit tests before upgrading. No documented breaking changes, but no documented fixes either.
Rule conflicts: when several rules apply to one product, define precedence explicitly (most restrictive wins, or priority field). Undefined ordering is a classic source of “limit sometimes not enforced” bugs.
Guest customers: decide what “per customer” means when there is no user ID; session- or email-based keys behave differently and are easy to bypass.
Caching: cached rule sets are the usual cause of “I changed the limit and nothing happened.” Invalidate on save/delete and consider a short TTL as a safety net.
Quantities and variants: watch for unit mismatches (cases vs. units) and parent/variant SKUs; normalize before comparing against limits.
Extension points: prefer subclassing the bundle's rule contract and registering custom rules over editing vendor code. If the bundle exposes events/subscribers, hook order placement there so limits stay enforced outside the web checkout path (API, admin re-order).