Workbench Laravel Package

Product Decisions This Supports

• Codebase topology: modular monolith vs. multi-repo. Workbench makes "package-per-domain" viable inside a single Laravel application. This is the decision it most directly unlocks: do we enforce module boundaries with Composer autoload rules and a workbench/ scratch space, or do we defer that and accept a flat app/ directory? Choosing packages early is cheap; retrofitting them at 100k LOC is a quarter of platform work.
• Build vs. buy for internal developer tooling. The scaffolding, autoload wiring, and local symlink/linking that Workbench provides is exactly the class of internal tooling a platform team would otherwise spend 4–8 engineer-weeks building and then maintain forever. Default answer: buy (i.e., use the framework's).
• Shared-library strategy across products. If the roadmap includes two or more Laravel apps (customer portal + internal admin + API), Workbench is the mechanism for developing a shared domain package locally against both hosts before publishing — this is a roadmap-enabling decision, not a feature.
• Time-to-first-PR for new engineers. Package scaffolding that "just works" is a measurable onboarding lever. Worth tracking as a platform KPI (days from laptop setup to merged PR).
• Release/versioning posture. Packages developed this way are candidates for independent semantic versioning. This commits you to a release process (tags, changelogs, upgrade guides) — a real ongoing product-operations cost that should be scoped before adoption, not after.
• Where it does not drive decisions: it is not a runtime feature, not customer-facing, and has no direct revenue or performance impact.

When to Consider This Package

Consider it when:

• You are on a currently supported Laravel version and want to extract domain modules (billing, identity, notifications, integrations) into Composer packages without standing up separate repositories.
• Your team wants to develop an internal or open-source package alongside the host app, iterating on both in one working tree, with tests running against the real app.
• You are standardizing a starter kit or template across client projects and need reusable modules.
• You want zero new third-party vendor risk: this ships as part of laravel/framework and is developed by the framework maintainers.

Look elsewhere — or stop here — when:

• You intend to composer require illuminate/workbench directly. It is a read-only subtree split of the framework. You already have it. Requiring it explicitly risks version drift against laravel/framework; treat it as an internal component, not an adoptable dependency.
• You are not on Laravel, or are maintaining a legacy Laravel version predating the component.
• Your need is monorepo tooling across polyglot services (JS + PHP + Go). Workbench is PHP/Composer-scoped; you want Nx/Turborepo-class orchestration plus Composer path repositories.
• You need private package distribution at scale — that is Satis, Private Packagist, or a Git-based VCS repository, not this.
• Your packages must be consumed by external third parties with independent support SLAs; the dev workflow is the easy part, the release/support commitment is the expensive part.
• The team's modularity problem is actually runtime decoupling (separate deployables, queues, failure isolation). Packages do not give you that. Do not let "we adopted Workbench" substitute for a service-boundary decision.

How to Pitch It (Stakeholders)

For executives (30 seconds). This is not a new vendor. It is a development-only component that already ships inside the Laravel framework we have licensed at zero cost. It reduces the internal tooling we would otherwise have to build and maintain to organize our codebase into reusable modules, and it carries no runtime footprint, no production dependency, and no recurring fee. The decision on the table is architectural, not commercial: whether to invest in module boundaries now, using tooling we already own, or pay for that restructuring later.

For engineering leadership. Adopt the framework's native package-development workflow as the standard for any internal package or shared module. Benefits: one working tree for host app and package, tests against the real application, no bespoke symlink scripts, no divergent in-house scaffolding to maintain. Constraints to accept: it is a dev-only dependency, it tracks the framework version (upgrade in lockstep with Laravel), and it is explicitly read-only — we do not fork it. If we need it, it comes with the framework; nobody should add it to composer.json by hand.

Risk and effort. Risk: low. No production surface, no license, no vendor negotiation, maintained upstream. Effort: near zero to enable; the real cost is organizational — committing to package ownership, versioning, and release discipline. Approve the workflow, but require a named owner and a documented release process before the first package is extracted.