Weave Code
Workbench Laravel Package
illuminate/workbench
Illuminate Workbench gives Laravel developers a dedicated local workspace for building packages. Scaffold new packages, wire up service providers and autoloading, run tests, and iterate on reusable components quickly with Artisan commands before publishing them to Packagist.
[READ ONLY] Subtree split of the Illuminate Workbench component (see laravel/framework)
Frequently asked questions about Workbench
- What is illuminate/workbench used for?
- Workbench is Laravel's local package development harness. It lets you scaffold a package inside a host application, register its service provider, wire up routes, migrations, views, and tests, then iterate with Artisan commands before publishing to Packagist. It is developer-time tooling only and has no role at application runtime.
- Should I add illuminate/workbench as a production dependency?
- No. Workbench is a developer-time harness with no business value at runtime, so it belongs only in require-dev if it is used at all. The recommended path is to consume the tooling through laravel/framework or the first-party laravel/workbench package. Keeping it out of production also avoids duplicate Illuminate\Workbench namespace entries in your autoloader.
- Is illuminate/workbench the same as laravel/workbench?
- This repository is a read-only subtree split of the Workbench component that lives inside laravel/framework. The code is the same component, published as a mirror for reference and per-package installation. The supported ways to get it are the framework's bundled copy or the first-party laravel/workbench package.
- How do I set up Workbench to develop a Laravel package locally?
- Usually you get Workbench through laravel/framework or laravel/workbench, then use the workbench Artisan commands to scaffold a package, register a service provider, and add routes, migrations, views, and tests. The scaffold lives in a packages directory inside your app so you can iterate quickly against a real Laravel host. Only add a direct --dev requirement if the capability is not already available from your framework constraint.
- Which Laravel and PHP versions does illuminate/workbench support?
- The split is generated per framework tag, so its versions track Laravel releases and it inherits the framework's PHP 8.x baseline. Workbench is bundled in Laravel 10 and 11, so most teams already have it without a separate requirement. Always check the split tag against the framework version in your lockfile before pinning.
- Why does this repository have no issues or pull requests?
- It is marked READ ONLY because it is an automated subtree split of laravel/framework. All issues, pull requests, security policy, and release notes live upstream in the framework repository. That is a distribution decision rather than a sign of abandonment.
- Is illuminate/workbench abandoned because it has so few stars?
- No. The low star count reflects the fact that this is a mirror, and nobody stars a split repository. Quality, maintenance, and security are governed upstream by laravel/framework. Judge the component by the framework's release cadence rather than by this mirror's metrics.
- How is Workbench different from Orchestra Testbench?
- They are complementary rather than competing. Workbench is for interactive package development inside a host application, while Testbench provides a test harness for running package test suites in isolation. Many teams use both: Workbench to build and iterate, Testbench to test.
- How do I fix a duplicate Illuminate\Workbench class or composer conflict?
- That error usually means the same namespace is being pulled from both laravel/framework and the split. Remove the direct illuminate/workbench requirement, re-resolve the lockfile in a branch, and confirm the capability still resolves from the framework or laravel/workbench. Running composer why and composer why-not proves the dependency graph is clean and unambiguous.
- Should I pin illuminate/workbench to a specific version?
- Pinning the split is effectively pinning the framework indirectly, so it is better to enforce a single laravel/framework constraint at the root and let the split float with it. Mixing an 11.x split into a 10.x application is the failure case to design out. Group framework packages in your dependency automation so the split can never upgrade independently.
Weaver
How can I help you explore Laravel packages today?