Laravel Module Loader Laravel Package

Product Decisions This Supports

• Production observability rollout for modular monoliths. v7.1.1 adds a configurable sampling rate for module profiling, which turns module-level profiling from an "all-or-nothing" debugging tool into something you can leave on in production at a fraction of requests. This directly unblocks decisions like "can we get per-module latency data in prod without tanking throughput or blowing up log/storage costs?"
• Performance budget ownership per module. If you're splitting a monolith into modules (or already have), profiling data per module is what lets you assign a latency/query budget to a team or module owner. Sampling makes that affordable at scale, which supports roadmap decisions about where to invest refactoring effort.
• Feature-flag / staged-rollout decisions. A sampling knob is effectively a dial you can turn up during an incident or a canary and back down afterwards — useful input for release-gating and "is this module regression real or noise?" conversations.
• Build vs. buy. Rolling your own module profiling (middleware + timing + aggregation + sampling + config surface) is a few days of engineering plus ongoing maintenance. If the rest of the module-loader's semantics fit your architecture, adopting this is the cheaper path; the sampling feature closes the main "but it's too expensive to run in prod" objection.
• Use cases to validate: measuring per-module boot/registration cost, identifying slow modules under real traffic, correlating module cost with specific endpoints, and justifying (or killing) a modularization initiative with data.
• Upgrade risk is low. v7.1.1 is a single additive feature on top of v7.1.0 — no breaking changes, no deprecations. This is a safe bump to take opportunistically rather than a scheduled migration.

When to Consider This Package

Consider it when:

• You run a Laravel modular monolith (or are moving toward one) and need modules to be discoverable/loadable with predictable conventions, rather than hand-wiring service providers.
• You want module-level profiling in production, not just locally — the new sampling rate is the deciding feature here. If sampling didn't exist, prod profiling was a hard sell.
• You need per-module performance data to support ownership, budgets, or a modularization roadmap.
• Your team is comfortable with a third-party package governing module boundaries and boot order — this is an architectural dependency, not a utility.
• You can pin to ^7.1 and take patch releases on a normal cadence.

Look elsewhere / proceed cautiously when:

• Your app is a single small Laravel app — the module abstraction is overhead with little payoff, and profiling a handful of controllers doesn't need a framework.
• You already have APM/tracing (Datadog, New Relic, OpenTelemetry, Laravel Telescope/Pulse) covering the same ground. Module-level granularity may still be additive, but validate before layering two profiling stories.
• You need guaranteed long-term support, a large community, or vendor SLAs — this is a small, opinionated package from a single organization; bus-factor and upgrade-path risk should be assessed explicitly.
• You need profiling that's sampled across the whole request lifecycle (DB, queues, outbound HTTP) rather than module-scoped timings.
• You're on an older Laravel major — confirm the version matrix before committing, since this is a v7 package with its own major cadence.

Adoption criteria I'd want met: a documented config surface for the sampling rate, a clear statement of what "module profiling" measures, confirmation that sampling applies per-request (not per-module) so results are statistically comparable, and a benchmark of overhead at 100% sampling.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're evaluating a Laravel package that standardizes how our application is split into modules and — as of this release — lets us measure how expensive each module is in production, on a controlled percentage of traffic. The practical value is that we can attach a performance cost to each part of the product and make roadmap and refactoring investment decisions on evidence rather than intuition, without paying the full cost of always-on profiling. The upgrade itself is small and low-risk (a single additive feature, no breaking changes); the real decision is whether we want module-level performance visibility as a standing capability.

For engineering (the short version):

• v7.1.1 adds a sampling rate for module profiling. Previously, profiling was effectively all-or-nothing; now we can enable it on, say, 1–5% of requests in production and still get usable per-module latency distributions.
• No breaking changes. Additive config; safe patch bump from v7.1.0. We should still pin and test in staging.
• What we need before shipping it on: the exact config key and default (verify sampling defaults to off, not 100%), confirmation that sampling is consistent per-request so module timings remain comparable within a sample, and an overhead measurement at 1% / 10% / 100%.
• What it does not replace: request tracing, query analysis, or queue/outbound instrumentation. Treat this as module-granularity timing, complementary to our existing APM.
• Open question worth answering early: if we adopt this, the module loader becomes a load-bearing architectural dependency. Worth a short review of its release cadence, maintainer concentration, and upgrade history before we build conventions on top of it.