Interlock Laravel Package

Product Decisions This Supports

• Modular monolith vs. microservices. Interlock makes "one deployable, many bounded modules" a first-class, enforceable option. This is the key architectural fork: it lets you defer the operational cost of service decomposition (separate pipelines, infra, observability, distributed tracing, cross-service auth) while still drawing domain boundaries that are visible in the filesystem and in code. The decision it supports is "stay a monolith for the next 12–18 months without the codebase turning into a ball of mud."
• Build vs. buy for module tooling. The alternative is hand-rolled conventions (a app/Modules/* folder plus bespoke service-provider registration) or an existing modules package. Interlock bundles discovery, scaffolding, and generator parity in one dependency, which reframes the decision from "do we write our own module loader?" to "do we adopt this and contribute, or fork?"
• Developer velocity and onboarding cost. module:make with part selection (--web, --api, --views, --lang, --migrations, --factories, --seeders, --tests, --all) plus custom stubs turns "here is our 40-step new-module checklist" into one command. That is a measurable onboarding lever: time-to-first-merged-PR for a new hire, and cost per new bounded context.
• Convention enforcement as a product-quality control. Custom stubs with placeholders mean the house style (logging, base classes, test scaffolding, DTO patterns) is encoded in tooling rather than in a wiki page people stop reading. This directly affects defect rates and review latency.
• Ecosystem optionality. module:action activates only when lorisleiva/laravel-actions is present; module:data only when spatie/laravel-data is present; Livewire namespacing is opt-in. The package does not force a stack decision, so it can coexist with a roadmap that hasn't settled on actions/DTOs/Livewire yet. That keeps later technology bets reversible.
• Incremental adoption as a rollout strategy. Per-type toggles under interlock.discover and configurable interlock.routes and interlock.directories mean a pilot module can ship before a company-wide mandate. This is the difference between a 2-week spike and a 6-month migration program.
• Performance and CI as a first-class concern. module:cache / module:clear hooked into optimize and optimize:clear, plus autoloading through wikimedia/composer-merge-plugin that survives optimised and authoritative classmaps, means the architecture does not impose a production or CI tax. "Modularity costs us latency or build time" is a common objection this pre-empts.
• Generator parity reduces switching cost. Thirty module:* counterparts of Laravel's make:* generators with identical options plus --module means engineers keep muscle memory and documentation stays accurate. That is a concrete adoption-risk reduction, and a reason to prefer this over a homegrown loader.
• Platform-team roadmap input. Gaps in the release notes are candidate backlog items: no mention of module-level config publishing/merging, no dependency-graph or boundary-violation linting, no module:remove/module:rename. If boundary enforcement is the strategic goal, boundary checking is the natural next investment (in-house or upstream).

When to Consider This Package

Adopt when:

• You are on (or can commit to) Laravel 13 and PHP 8.5+. This is the hard gate. The release targets the newest runtime line; there is no stated LTS/backport path here, so a team on Laravel 11/12 cannot use it at all. Verify this against your upgrade roadmap before anything else — it converts the decision into a sequencing question ("do we bring forward the framework upgrade to get the modularity tooling?").
• You have a single Laravel monolith with roughly 5–15+ engineers and recognisable domain seams (billing, catalog, notifications, identity) that are stable enough to name.
• You want enforced folder-level boundaries without infrastructure spend, and you accept that boundaries are conventional, not runtime-enforced — a module can still reach into another's classes unless you add your own static analysis.
• Developer experience is a stated bottleneck: slow module bootstrapping, copy-paste scaffolding, inconsistent structure across teams.
• You have a named owner (platform lead / staff engineer) who will own the convention, the stubs, and the upgrade cadence. This is a tool that rewards stewardship and decays without it.

Look elsewhere when:

• You cannot move to Laravel 13 / PHP 8.5. Then the honest answer is "revisit at upgrade time," and the fallback is documented conventions plus a small custom discovery provider.
• You genuinely need independent deploy cadence, per-domain scaling, or fault isolation. Modules in one process share a failure domain, a memory limit, and a deploy. If those are hard requirements, this package is the wrong shape and you should be talking about service extraction or a package-per-domain monorepo.
• You already run a mature composer package monorepo with real versioning and separate CI per package. Interlock's discovery is a lighter-weight answer to a problem you have already solved differently; adopting both creates two competing notions of "module."
• You are highly risk-averse about dependency health. v1.0.0, a young project, and a bleeding-edge framework floor together mean you should treat this as a bet on a maintainer, not a bet on an institution. Require a fork-and-own plan (small surface area, MIT-style licensing, mostly conventions) before adopting on a revenue-critical path.
• The team lacks the discipline to respect boundaries. The tool makes modules easy to create; it does not stop cross-module coupling. If the org's default is to reach across seams, you will get the folder structure and none of the benefit — you will have paid the tooling cost for cosmetic modularity.

How to Pitch It (Stakeholders)

For executives (one paragraph): We are proposing to structure our Laravel application as a modular monolith — one application, one deploy, but internally divided into clearly named business domains with a shared, standardised way of adding new ones. This buys us most of the organisational benefit of splitting into services (clear ownership, independent feature teams, contained blast radius for changes) without the operational bill: no new infrastructure, no separate deployment pipelines, no distributed-systems complexity. Concretely, it targets two costs we already feel: slow onboarding into an increasingly tangled codebase, and inconsistent structure across teams. The main caveat is a version dependency — the tooling requires the newest Laravel and PHP releases, so adoption is tied to our framework upgrade timeline, and it is a young project, so we would pilot it on one module and keep a fork-and-own fallback rather than betting the platform on it unexamined.

For engineering leadership: The pitch is developer velocity and structural consistency, not architecture astronautics. module:make replaces a manual checklist with a single command that produces web/api routes, views, translations, migrations, factories, seeders and tests on demand, and custom stubs let us bake our own conventions in so new code looks like our code by default. Thirty module:* generators mirror Laravel's own make:* commands with identical options plus --module, so there is essentially no relearning. Discovery is automatic but controllable: each type (routes, views, translations, components, commands, listeners, migrations, factories) can be toggled off, route groups are chosen by filename with web and api on by default, and a cached discovery manifest is wired into optimize and optimize:clear so we get production boot performance for free. Autoloading runs through wikimedia/composer-merge-plugin so optimised and authoritative classmaps still work — no CI surprises. Livewire, laravel-actions and spatie/laravel-data are picked up only if we already use them, so this does not pre-commit us to a stack. What we are asking for: approval for a scoped pilot on one non-critical module, contingent on our Laravel 13 / PHP 8.5 upgrade timeline, with a written exit plan (the discovery layer is thin enough to reimplement in-house if the project stalls). What we are not claiming: this does not enforce boundaries at runtime, and it does not replace a decision about eventual service extraction — it defers that decision cheaply, which is the point.