Laravel Features Laravel Package

Product Decisions This Supports

• Modular monolith vs. microservices: This package lets a single Laravel codebase be sliced into self-contained "features" (routes, migrations, seeders, commands, translations, config, views). That makes "stay on a modular monolith" a defensible roadmap decision rather than a compromise — you get module boundaries without paying for distributed-systems overhead.
• Build vs. buy for internal modularization: Rather than spending engineering cycles building an in-house feature/module loader, adopt this package as the isolation layer and reinvest saved effort into product surface area. Low-risk "buy" decision since the dependency is small and framework-native.
• Team-scaling and ownership model: Features map cleanly to squads or verticals (e.g., Billing, Onboarding, Reporting). This supports org decisions like "one team owns one feature directory" and reduces cross-team merge conflicts — a concrete enabler for parallel roadmap execution.
• Feature flags / progressive rollout adjacency: Because features are discrete units with their own routes and commands, the package makes it practical to enable, disable, or extract a capability later — useful for phased launches or de-scoping a feature post-launch without ripping out code.
• Roadmap flexibility (v1.1.0): Per-feature console commands and per-feature translations mean new capabilities can ship as complete vertical slices — UI, background jobs, cron tooling, and localized strings — without touching global bootstrap files. Closure route groups reduce boilerplate when a feature needs shared middleware/prefixes, lowering the cost of adding new route surfaces.
• Localization / market expansion decisions: Feature-scoped translations make it cheaper to localize one feature at a time, which supports a "expand into market X incrementally" strategy rather than a big-bang i18n program.
• Operational tooling inside features: Command registration means scheduled jobs, backfills, and admin utilities live with the feature that owns them — supporting decisions about where operational/runbook tooling belongs and who maintains it.
• Customization without forking (v1.2.0): Boot-time extension hooks let a feature's startup be augmented from outside — e.g., a customer-specific or plan-specific feature injecting behavior into a shared core module. This supports the roadmap decision to ship one core product with tiered/enterprise variations, rather than maintaining fork-per-customer or building a plugin system from scratch. It also gives teams a sanctioned seam for cross-feature integration, which is where most modular architectures quietly degrade into tangled imports.
• Platform maturity as a gate: The v1.2.0 review pass touching registry, discovery, route groups, and filesystem/disk handling is a hardening release rather than a feature release. For roadmap planning this is a positive signal on the core abstraction's stability (fewer surprise edge cases in discovery and path resolution), but it does not change the adoption calculus on maintainer depth.

When to Consider This Package

Consider adoption when:

• Your Laravel app is outgrowing a flat app/ structure and cross-cutting edits are becoming a coordination tax across teams.
• You want modular boundaries without splitting into services, separate deployments, or a package-per-domain internal registry.
• You have (or plan) multiple squads or verticals that need clear code ownership.
• You want features to be portable/composable — potentially extracted into a package or reused across products later.
• You need background commands, translations, routes, and seeders to travel together as a unit — v1.1.0 made feature slices materially more complete, and v1.2.0 adds an extension seam so slices can be customized rather than only reused verbatim.
• You anticipate plan-tier or customer-specific variation on top of a shared core, and want that variation expressed as boot-time hooks instead of conditional spaghetti inside the feature.
• You're seeding demo/staging environments and need reliable seeder discovery (the v1.1.0 fix for ::class-referenced seeders, plus the v1.2.0 discovery/registry hardening, address a real friction point in test/staging data setup).

Look elsewhere when:

• The app is small (single team, few domains) — the indirection cost likely exceeds the benefit; conventional Laravel structure is fine.
• You need hard runtime isolation, independent deploy cadence, or language-agnostic boundaries — that's a services/queue/event-driven architecture question, not a package question.
• You need a full plugin/extension ecosystem with versioned third-party APIs — boot hooks are a lightweight internal seam, not a public extension contract. If extensibility by outside developers is the requirement, plan on building the contract and versioning yourself.
• You require mature, heavily-adopted tooling with a large ecosystem; this is a relatively young, single-maintainer-led package (both v1.1.0 and v1.2.0 work is by one contributor), so bus-factor and long-term support should be weighed.
• Your organization mandates vendor-backed support contracts — there's no commercial backing here.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost library that lets us organize our Laravel application into clean, self-contained product modules. It's an enabler for scaling the team without scaling headcount-per-feature or splitting into expensive microservices. Since our last review, the package has rounded out the module story — features own their commands, translations, and routing — and now supports extensions at boot, which lets us ship a single core product with tiered or customer-specific variation instead of maintaining forks. The latest release is primarily a hardening pass on discovery and routing, which is the kind of release we want to see on a foundational dependency. Risk remains modest (small dependency, framework-native), and the escape hatch is real: modules can be extracted later if we ever need to.

To engineering: Adopt this as the structural convention for domain modules. v1.1.0 closed the most annoying gaps — commands and translations register per-feature (no more editing global Kernel/lang files), route groups can be closures, and seeder discovery resolves ::class references. v1.2.0 adds boot-time extension hooks, giving us a sanctioned place to augment a feature from outside it (plan gating, customer overrides, cross-feature wiring) without editing the feature itself — treat this as an internal seam, not a public plugin API, and document the hooks you rely on. The rest of v1.2.0 is a review/fix pass across registry, discovery, route groups, and disk handling, so expect fewer path-resolution and discovery edge cases, and re-run your staging seeder and route-cache checks on upgrade. Caveat: still a single-contributor codebase, so pin versions, review releases, and keep an abstraction seam so we're not hard-coupled if we need to swap the loader out.