Modularize Laravel Package

Product Decisions This Supports

• Build vs. buy for module-aware CLI surface. If we maintain packages that ship Artisan commands and our customers (or our own teams) run a modular Laravel codebase, this package replaces the "write --module parsing, path resolution and namespacing ourselves, per command" work with a two-trait convention. The buy decision is cheap (one Composer line, MIT), but the real decision it informs is standardize the CLI contract once versus let each package invent its own --module semantics.
• Roadmap: how far do we lean into internachi/modular? Adopting this is a soft commitment to that ecosystem as our module runtime. It's the right lever if modularization is already on the roadmap; it's a distraction if we're only experimenting with module boundaries.
• Scope of the "same command, plus an optional scope" pattern. The package's value proposition is that every command behaves identically with and without --module. That's a product promise we can make to users ("any module-aware command accepts --module=<Name>"), and a compatibility contract we have to protect — the non-module path must stay byte-identical.
• Developer-experience investment for generator commands. Scaffolding into the right directory with the right namespace is the highest-friction part of modular Laravel work. This package converts that from tribal knowledge into a flag — a measurable DX win if we track onboarding time or "file landed in the wrong place" incidents.
• Package-authoring architecture decision. Choosing base command/base generator classes as the integration point (rather than per-command traits) is a one-time structural decision that determines whether future commands get --module for free or need repeated edits.
• Use cases it unlocks: package commands that target a module's data or resources (feed sync, index rebuild, migrations); generators that scaffold controllers/jobs/factories into modules/<Name>/...; internal tooling that must run the same operation app-wide or module-scoped.
• Deprioritization signal. Zero dependents and a two-star repo mean we should not build product strategy on top of this package. It supports a narrow tactic; it is not a platform bet.

When to Consider This Package

Adopt when all of the following hold:

• We maintain a package (or several) that registers Artisan commands, and we want those commands to accept --module.
• The host application already uses internachi/modular and has working module registration — without it, $this->module() resolves to null and the traits do nothing.
• We're willing to own the namespace/path override hooks in our own base classes; the "automatic" placement only becomes automatic after that wiring.
• Our Laravel version is inside the supported constraint (1.1.1 added ^13), and we're prepared to re-run the command test suite on Laravel/Symfony console upgrades.

Look elsewhere or skip when:

• We're building an application, not a package. End apps should depend on internachi/modular, not this — it's a dependency of packages that ship commands.
• We need runtime/dynamic module resolution at request time; this is CLI-only and does nothing outside the console.
• We don't use internachi/modular (or use a different modularization approach, e.g. nwidart/laravel-modules) — the traits resolve nothing.
• We need a batteries-included module system (discovery, registration, config publishing). This package has no service provider, no config, no container bindings.
• Supply-chain risk tolerance is low and we can't accept a single-organization, single-maintainer dependency with zero dependents — in that case, vendoring the two trait files (small, narrow API, MIT) is the honest alternative and worth explicitly pricing against adoption.

How to Pitch It (Stakeholders)

The one-liner: A tiny, MIT-licensed adapter that gives our package's Artisan commands a consistent --module=<Name> option, so a command works identically app-wide or scoped to a module — no bespoke flag parsing, no path guessing.

For executives: It's a low-cost consistency play. Instead of each package inventing its own way to target a module, we standardize one CLI convention across our tooling. Cost is a single dependency and a small amount of per-package wiring; benefit is fewer support issues, faster onboarding, and scaffolding that lands in the right place with the right namespace. The strategic dependency is internachi/modular, so this only makes sense if modularization is already part of our direction.

For engineering: Two traits, no service provider, no config, no runtime code. Modularize adds the option and hands you a read-only ModuleConfig; ModularizeGeneratorCommand adds the option and handles file placement for generators. The honest caveats: you must override getDefaultNamespace() (and getPath() for migrations, seeders, jobs, factories) yourself — otherwise generated classes compile with App\... imports inside a module. Null is the default, so guard $this->module() once at the top of handle() and keep the non-module path unchanged. Integration cost is one base command class plus one base generator class, then every concrete command inherits the behavior.

Risks to state plainly: Two stars, zero dependents, single-organization ownership, and a narrow API. Mitigate by pinning ^1.1, confining the trait to our base classes so a future ModuleConfig change is a one-file shim, and running a with/without --module test matrix so the default path can never regress. If the risk is unacceptable, the fallback is copying the two small trait files under MIT.