Statamic Cargo Laravel Package

Technical Evaluation

Scope of this review. No prior assessment exists and the only evidence supplied is the v1.15.1 release notes, so everything below is a provisional, release-notes-only evaluation. It should be re-baselined once we have the composer manifest, the Statamic/Laravel version constraints, and a read of the stock-event and tax-class code paths.

Architecture fit. Statamic Cargo is a first-party-authored e-commerce addon for Statamic (built on Laravel), so it fits the same architectural slot as the rest of the Statamic addon ecosystem: content lives in Statamic entries, commerce state is mirrored into Eloquent-backed Cargo models, and business logic runs through Laravel service container bindings, events, and listeners. For a team already on Statamic + Laravel, this is a low-friction fit — no second admin surface, no separate content store, no bespoke auth. For a team on plain Laravel with no Statamic, the fit is poor: you inherit Statamic's content model, its upgrade cadence, and its hosting assumptions for what may be a small storefront.

What v1.15.1 actually tells us. This is a patch release containing four fixes, three of them in the same problem neighborhood:

1. Stock event dispatch now checks the variant's stock, not just the product's. This is the most significant line. It implies that prior to this patch, variant-level stock events could fire against the wrong stock source. Stock events are the hooks that drive availability, oversell prevention, and downstream inventory/ERP sync.
2. Empty tax class passes validation — a validation bug that would have blocked saves on legitimate configurations.
3. Variants of products without a tax class return no tax class rather than inheriting something incorrect. A tax correctness fix.
4. Dependabot bump of the GitHub Actions group — CI hygiene, zero runtime impact.

The clustering of #318–#320 (all authored by the same contributor, all variant/tax-class correctness) is the real signal: the variant dimension of the data model is where defects are concentrating, and these are correctness defects with money attached, not cosmetic ones.

Integration feasibility. High, conditional on Statamic version. Installing is a composer require plus publishing config/migrations; cart, checkout, orders, products, and variants come with it. The nontrivial work is not installation but the seams: payment gateway, tax provider, shipping rates, and any ERP/inventory system consuming the stock events. The v1.15.1 change is directly relevant to that last seam — if we consume stock events, we should verify our listener assumptions against the corrected variant-aware behaviour before cutover, not after.

Technical risk. Moderate. The version number (1.15.x) signals a mature-ish but still pre-2.0 addon: semver permits minor-version breaking-ish behaviour changes, and this release demonstrates that bug fixes can change event payload semantics. Tax logic is a regulated-output risk — a wrong tax class on a variant is a compliance and customer-trust issue, not a bug ticket. And single-contributor concentration across three consecutive fixes is a bus-factor concern for the upstream dependency.

Key questions before committing.

• Which Statamic and Laravel major versions does 1.15.x pin, and are we inside that window?
• Does any fix in 1.15.1 change observable behaviour for existing data — specifically, do previously-saved variants with null tax classes now resolve differently at checkout?
• Are we emitting or consuming stock events? If consuming, what is our listener contract when the event now reflects variant stock rather than product stock?
• Who owns the upstream relationship, and is there a second maintainer?
• What is the tax-class fallback semantics we actually need (inherit from product vs. explicitly none), and does #320's "return no tax class" match our finance team's expectation?
• Is there a changelog covering 1.15.0? We only have the patch notes.

Integration Approach

Stack fit. Presupposes Statamic (with Laravel). Confirm the Statamic major version matches the addon's constraint before anything else — that single check invalidates or validates the whole plan. If we are on Statamic 4/5 with a current Laravel LTS, fit is good. The addon uses standard Laravel idioms (events, validation, Eloquent), so it will not fight our existing conventions.

Migration path. Treat this as a greenfield commerce integration rather than a migration, unless we are replacing an existing storefront — in which case product/variant/order data mapping is the dominant effort, not the code. Sequence:

1. Pin duncanmcclean/statamic-cargo at ^1.15.1 (not ^1.15) so we take the variant stock and tax-class fixes and stay on patch updates within a known-good minor.
2. Stand up a non-production Statamic instance, publish config and migrations, and model a realistic catalogue: multi-variant products, at least one product with no tax class, at least one with an empty-string tax class. Those two are precisely the shapes #319/#320 touch.
3. Wire payment, tax, and shipping drivers in the sandbox and run orders end-to-end.
4. Only then integrate stock events with any inventory system, validating against variant-level stock.

Compatibility. The three functional fixes are behavioural corrections, not API breaks — no deprecations are announced. The practical compatibility question is data compatibility: existing variants persisted under the old tax-class resolution may now resolve differently. Run a data audit query for variants whose parent product has a null or empty tax class before and after upgrading, and diff the resolved values.

Sequencing. Do not bundle this upgrade with an unrelated platform change. Land 1.15.1 on its own, with a regression pass over (a) stock availability for multi-variant products during checkout concurrency, and (b) tax computation for the null/empty tax-class cases. Then, and only then, proceed with gateway and ERP integrations.

Operational Impact

Maintenance. Low day-to-day, moderate on upgrade events. Dependabot activity in the repo is a good sign for CI hygiene; a patch release eleven days into the 1.15 line indicates active upkeep. Budget for a deliberate upgrade review at each minor bump rather than blind patch updates, given that fixes here can alter event semantics.

Support. Statamic addon support is community/GitHub-issue driven, not a vendor SLA. Our internal team must own the integration layer. Because the tax and stock logic is now demonstrably subtle, designate one engineer as the named owner of this dependency with authority to block upgrades.

Scaling. Commerce load is dominated by checkout concurrency, not catalogue reads. The variant-stock fix is directly a scaling-adjacent concern: correct variant-level stock checks are what prevent oversell under concurrent checkout. Beyond that, scaling characteristics follow Statamic's caching model and the database — plan for read caching of product pages and a queue for order post-processing. No evidence in these notes of a scaling regression.

Failure modes to instrument.

• Oversell: variant stock decremented below zero or two orders confirming the last unit — the exact class of bug #318 addresses. Alert on negative variant stock.
• Tax misapplication: order total mismatch between checkout and invoice, or zero-tax orders that should be taxed. Alert on tax-rate-anomaly orders and reconcile periodically against the tax provider.
• Silent event loss: stock events dispatched but not consumed by downstream inventory, producing drift between Cargo and the ERP. Monitor event dispatch vs. consumption counts.
• Validation regression: checkout save failures on legitimate configurations (the #319 shape) surfacing as abandoned carts with server errors.
• Upstream abandonment: no release for an extended period while Statamic/Laravel majors move on.

Ramp-up. One to two weeks for a Laravel-fluent engineer to be productive in the sandbox, mostly spent on Statamic content modelling rather than Cargo itself. Add roughly a week for whoever owns tax and inventory integrations, because the variant/product dual-stock and tax-class-fallback semantics need to be understood explicitly, not inferred. Onboarding material should include the specific edge cases from #318–#320 — they are the best available documentation of where this addon is genuinely tricky.