Laravel Modules Interactions Laravel Package

Product Decisions This Supports

• Platform upgrade sequencing (Laravel 13 / PHP 8.4). v2.0.0 is a requirements-only major: it drops Laravel 12 and PHP 8.3 and adds nothing application-facing. That makes it a clean signal for roadmap planning — this package can be slotted into the same upgrade wave as the rest of the Laravel 13 migration, and it will not be the thing that blocks it (no API changes, no data migration, no config changes).
• Build vs buy for counter mechanics. The release deliberately replaced a hand-interpolated DB::raw('count + (n)') with the query builder's increment()/decrement(). That is exactly the class of code a team would otherwise hand-roll per model, and get subtly wrong under concurrency. The package's value proposition is "atomic, correct counter deltas plus Filament surfacing plus module wiring" — keep buying while that stays true.
• Admin UI roadmap independence. Filament ^3.0 || ^4.0 || ^5.0 all verified against Laravel 13 in CI means the admin surface can move on its own cadence without being coupled to the Laravel upgrade. If we have Filament 3 screens today, we are not forced into a Filament 4/5 migration to get Laravel 13 support.
• Security and code-review posture. Keeping the delta out of the SQL string and conforming to Laravel 13's narrowed Connection::raw() typing removes a raw-SQL interpolation pattern from the codebase. That is a small but real reduction in review surface — worth citing in any security or static-analysis discussion rather than treating as an internal refactor.
• Modular monolith dependency. The ozankurt/laravel-modules-core ^2.0 requirement ties this upgrade to that package's v2 line. If our architecture uses modules, that is a coordinated two-package upgrade decision, not a single bump.
• Use cases this keeps viable: view/like/download/usage counters on module-scoped models, admin-visible metrics in Filament, anywhere an increment must be applied at the database rather than read-modify-write in PHP.

When to Consider This Package

Adopt (or upgrade to v2.0.0) when all of the following hold:

• The application is on Laravel 13 and PHP 8.4, or is upgrading to them in the same release train. There is no partial path — v2.0.0 will not install on Laravel 12 or PHP 8.3.
• You need atomic counter deltas (increment/decrement at the query level) rather than read-modify-write, and you want that behaviour packaged and tested rather than reimplemented.
• You use Filament 3, 4, or 5 for the admin surface, or you are willing to carry it as a dependency for the admin integration.
• Your app is a modular monolith already on ozankurt/laravel-modules-core ^2.0, or you are prepared to adopt it.
• You value a maintained CI matrix (PHP 8.4 × Laravel 13 × three Filament majors) as evidence the package tracks the ecosystem rather than lagging it.

Look elsewhere, or stay on the 1.x line, when:

• You are not yet on Laravel 13 / PHP 8.4. Staying on 1.x is the correct answer; do not let this package force a platform upgrade ahead of its own schedule.
• You need multi-dimensional or time-series counters (per-day buckets, cohorts, funnel-style metrics). A counter package is not an analytics store; reach for an event table or a dedicated analytics service.
• You are not using Filament and not using modules. The integration surface is the reason to buy; without it, a handful of increment() calls is cheaper than a dependency.
• You are dependency-averse on small-maintainer packages. This is a two-package chain (laravel-modules-core plus this package) with a hard-coupled major version pairing — weigh that against your appetite for coordinating majors twice.
• You need a supported LTS window longer than the maintainer's release cadence. The 2.0.0 cut drops a Laravel major immediately on release, which implies an aggressive support policy. Confirm that matches your upgrade tempo before committing.

How to Pitch It (Stakeholders)

For executives: This is a maintenance release dressed as a major — the version number moved because the platform floor moved (Laravel 12 → 13, PHP 8.3 → 8.4), not because the product changed. There is no application-facing API change, no data migration, and no user-visible behaviour change; the generated SQL is explicitly unchanged. The upgrade cost is a composer constraint bump plus making sure the host application is already on Laravel 13 and PHP 8.4. The upside is that we stay on supported platform versions and remove a raw-SQL string-interpolation pattern from the codebase in favour of the query builder's typed increment()/decrement(). The one real dependency to manage is ozankurt/laravel-modules-core ^2.0 — this upgrade and that one move together, so sequence them in the same ticket.

For engineering: Treat this as a platform-requirements major. Bump to ^2.0, confirm PHP 8.4 and Laravel 13 in composer.json and CI, and confirm laravel-modules-core is on ^2.0 in the same change — a partial bump will fail resolution. The counter internals changed from an interpolated DB::raw('count + (n)') to the query builder's increment()/decrement(), driven by Laravel 13 narrowing Connection::raw() to float|int|literal-string. Behaviour and emitted SQL are unchanged, so existing tests asserting on results should pass untouched; if you have tests asserting on raw SQL text, check them. Test tooling moves to Pest 5 and Testbench 11, and the CI matrix now covers Filament 3, 4 and 5 against Laravel 13 — meaning your Filament major is not gated by this upgrade. No config publishing, no migrations, no deprecation shims to chase.