Order Limit Bundle Laravel Package

Getting Started

• Confirm the framework fit before anything else. The Bundle suffix and the tourze/* vendor namespace are Symfony conventions, not Laravel ones. Open vendor/tourze/order-limit-bundle/composer.json and check require for symfony/framework-bundle or symfony/dependency-injection. If those are present, this is a Symfony bundle that happens to be installable in a Laravel app — Laravel will not auto-discover a service provider for it, and its DI extension/config tree (order_limit: style keys) won't be loaded.
• Install: composer require tourze/order-limit-bundle:^1.0.1
• First place to look: src/ for the limit-check contract (typically an *Interface plus a checker/validator service) and the tests directory. With a release note that is only a changelog link, the package's own tests are the de facto documentation — read them before reading the source.
• First use case: gate the cart→order transition with a purchase cap — e.g. "max N units of SKU X per customer per rolling window." Call the checker immediately before you persist the order, not at add-to-cart time, so you fail on the authoritative count.

If the framework check confirms Symfony-only, treat this as a library of domain services rather than a bundle: instantiate the checker yourself and wire it through a small Laravel service provider. Don't fight the bundle's Symfony DI config.

Implementation Patterns

• Bind the contract, not the class. In a ServiceProvider::register(), bind the package's limit-checker interface to its concrete implementation with your config injected. Keeps call sites testable and lets you swap in a stub in feature tests.
• Validate at the boundary. Wrap the check in a FormRequest (withValidator) or a dedicated EnsureOrderLimitNotExceeded middleware on the checkout route, and return a 422 with a machine-readable code. Avoid scattering the check across controllers.
• Check inside a transaction, not before it. The classic failure mode is check-then-write: two concurrent checkouts both read count = limit - 1 and both succeed. Either re-verify inside the same DB transaction that inserts the order, or take a lock on the customer/SKU row first.
• Make it idempotent for retries. Payment webhooks and job retries will re-run your order-creation path. Scope the idempotency key to the order attempt, and make the limit check a pure read so a retry doesn't double-decrement anything.
• Compose with Laravel validation. Where the package exposes a boolean check, adapt it into a custom Rule object so it composes with $request->validate([...]) and reports errors in the same shape as the rest of your validation.
• Cache the aggregate, invalidate on write. Counting orders per customer per window is a hot read. Cache the count with a short TTL and bust it in the order-created observer — but keep the transactional check as the source of truth.
• Scope limits by tenant. In multi-tenant apps, pass the tenant/store key explicitly into the checker rather than relying on ambient state; limits almost never span tenants.

Gotchas and Tips

• 1.0.1 is an undocumented patch. The release note is a bare changelog link with no listed changes. Pin 1.0.1 exactly, read the compare diff yourself (1.0.0...1.0.1) before deploying, and don't assume a patch bump is behavior-neutral in a package this young.
• No Laravel integration layer. Expect no service provider, facade, publishable config, or config/order-limit.php. You will write the glue: provider, config file, and any casting from Laravel's config array into the package's expected shape.
• Symfony config won't be published. The bundle's config tree lives in its DI extension. Don't look for php artisan vendor:publish output — there won't be any. Port the defaults by hand into a Laravel config file.
• Race conditions are the main production risk. Any limit system is a concurrency problem first and a business-rules problem second. Load-test the checkout path with parallel requests before trusting it.
• Debugging: log the rejection reason (which rule, which threshold, which observed count) at the call site. The package will likely return a boolean or throw a generic exception — you want your own context attached, or you'll be grepping logs blind.
• Extension points to look for: an event/listener hooked to limit rejection (for metrics and customer messaging), and a resolver interface for computing the applicable limit per customer/SKU. Those two seams cover most customization needs; if neither exists, wrap the package rather than forking it.
• Semver risk: at 1.0.x with a single patch release, treat the public API as still settling. Keep the package behind your own thin adapter class so a 1.1 rename costs you one file, not fifty call sites.