Laravel Module Laravel Package

Product Decisions This Supports

• Platform vs. single product. If the roadmap points toward an extensible Laravel application (SaaS, ERP, accounting, booking, CRM), this package supplies the module abstraction needed to ship features as independently versioned add-ons instead of a growing monolith. It is the enabling layer for a "core + modules" strategy.
• Build vs. buy for the modularization layer. Adopting it avoids designing and maintaining our own module convention (manifest format, discovery, service-provider registration, per-module routes/migrations/views/translations/assets, install/enable/disable/publish commands). The pattern comes from a shipping commercial product (Akaunting), which is a meaningful de-risking signal versus a greenfield in-house design.
• Roadmap sequencing and scope control. Modules let us deliver enterprise features, integrations, regional/vertical packs, and partner add-ons on their own release cadence without contaminating core scope. Beta or experimental features can ship to a segment as a module and be scaled or killed without core cleanup.
• Monetization and packaging. Modules map cleanly to paid SKUs, white-label bundles, per-tenant enablement, and feature flags — useful input for pricing and marketplace decisions. Note the package manages modules, not entitlements; billing/licensing remains ours to build.
• Operational and support decisions. Runtime enable/disable gives support a lever to turn features on per customer, which informs support tooling, upgrade/migration policy, and self-hosted deployment stories.
• Architecture and technical-debt decisions. Provides a strangler-fig path to carve an existing monolith into modules incrementally rather than a big-bang rewrite.

When to Consider This Package

Adopt when:

• You are on Laravel (verify the version compatibility matrix before committing) and want a module lifecycle with manifests, auto-discovery, per-module service providers, migrations, routes, views, translations, assets, and CLI install/enable/disable/publish.
• Your domain resembles ERP/back-office/accounting, where many optional features and regional variants are the norm — the conventions were built for exactly that shape.
• Modules must be installable and toggled at runtime by operators or tenants, not only via Composer.
• You can treat it as owned infrastructure: MIT license, small surface, readable source. Vendor/pin/fork it and document the conventions internally.
• You accept a lean, lightly opinionated package where the Akaunting source is part of the documentation.

Look elsewhere or pause when:

• You need heavy community support, extensive docs, and broad contributor coverage — nwidart/laravel-modules (~5k stars) is the default alternative and should be evaluated head-to-head on your Laravel version.
• Modules are only internal code organization. Laravel's native package structure plus Composer path repositories is simpler and avoids a bespoke abstraction.
• You need multi-tenancy, licensing, marketplace, or sandboxing — none of that ships here.
• You cannot accept Akaunting-specific conventions (directory layout, naming, helper functions like module_path() / module_asset()); adopting it creates real lock-in.
• Runtime installation of module code is a security or compliance concern you cannot control through supply-chain review.
• You need vendor-grade SLAs. Modest community signals (125 stars) and a single-vendor heritage mean critical-path use requires a fork/ownership plan and a documented upgrade cadence.

How to Pitch It (Stakeholders)

To executives: "We can convert our Laravel app into a platform where features ship as installable add-ons — faster time-to-market for paid and vertical features, per-customer enablement, and a credible path to an ecosystem. It's MIT-licensed and free, and the pattern is derived from Akaunting, a commercial product, so it isn't speculative. The trade-off is that it's a small open-source project with a single-vendor heritage: we should assume we own it. That means a modest, bounded engineering investment to vendor, pin, and fork it — not a vendor support contract."

To engineering: "It gives us module manifests, auto-discovery, per-module service providers, migrations, routes, views, translations, assets, and install/enable/disable/publish commands — the plumbing for a plugin architecture we would otherwise build and maintain ourselves. It's small enough to read end-to-end and fork. The honest counterpoint is that nwidart/laravel-modules carries far more community weight; run a one-week spike comparing both against our Laravel version and our runtime-install requirement, then decide. Whichever we pick, we pin the version, vendor it, and write down the conventions so the team isn't reverse-engineering them later."