Weave Code
Laravel Package Generator Laravel Package
tomatophp/laravel-package-generator
A Laravel package generator that scaffolds new packages in seconds, creating service providers, config files, routes, migrations, and the full directory structure. It automates boilerplate so developers can focus on building reusable, publishable Laravel packages faster.
TomatoPHP Laravel Package Generator is a developer tool that scaffolds complete Laravel packages from a single command. It generates the package skeleton, service provider, configuration, migrations, models, and folder structure following Laravel conventions, so you can skip repetitive boilerplate and start building your package logic right away.
Ideal for teams and solo developers who ship reusable Laravel components, the generator enforces a consistent, PSR-friendly layout while remaining fully customizable. Generated packages are ready to publish to Packagist or install locally via Composer.
- One-command package scaffolding with standard Laravel structure
- Auto-generated service providers, config, and migrations
- Convention-based, publish-ready output for Composer/Packagist
- Customizable stubs for tailoring generated files
Frequently asked questions about Laravel Package Generator
- How do I install tomatophp/laravel-package-generator?
- Install it as a dev dependency with composer require --dev tomatophp/laravel-package-generator, or install it globally so it stays out of your application's composer.lock. Laravel package auto-discovery registers the Artisan command, so no manual service provider registration is required. Pinning an exact version is recommended because the project has a single maintainer and stub drift becomes your problem.
- What files does the generator create for a new Laravel package?
- It scaffolds a composer.json, a service provider, publishable configuration, migrations, routes, views, translations, and the standard package directory structure. Everything it emits is ordinary first-party Laravel code following PSR-friendly conventions, with no runtime dependency on the generator itself. The result can live under packages/vendor/name as a path repository or be pushed as a standalone repository.
- Which Laravel and PHP versions do the generated packages target?
- The stubs are frozen at whatever Laravel and PHP major the maintainer targeted at the last release, so open the generated composer.json and raise the version floors to match your own CI matrix. If you need newer idioms, fork the stubs rather than patching generated output by hand each time. Validate the result with composer validate --strict, Pint, PHPStan, and Pest or PHPUnit on a real CI runner.
- Can I customize the stubs to match my team's conventions?
- Yes, the generator supports customizable stubs, so you can tailor generated files to your conventions instead of accepting the defaults. In practice teams wrap the raw vendor command in an internal make:package script that applies license headers, PHP and Laravel version floors, Pint/PHPStan/Rector configs, CI workflows, and README/CHANGELOG templates, then make that wrapper the artifact onboarding docs reference. Note the stock stubs lean toward the TomatoPHP and Filament ecosystem, so non-Filament stacks should prune or fork them before the output matches their architecture.
- Does the generator add a runtime dependency to the packages it creates?
- No. It is a developer-workstation scaffolder, not a runtime library, and nothing it produces depends on it at runtime. Keep it as a require-dev dependency or a global install so it never leaks into the generated package's dependency graph. Also review the generated composer.json to confirm no unwanted Filament or Splade dependencies are baked into the stub.
- How do I install a generated package into my Laravel app locally?
- Add a repositories entry of type path pointing at packages/<vendor>/<name>, then run composer update <vendor>/<name> so Composer symlinks the package into vendor. A path-repository monorepo keeps the package in sync with the host app while you develop it. Once the API stabilizes, split it into a standalone repository or publish it to Packagist.
- Is the generated package ready to publish on Packagist?
- It is designed to be publish-ready, with a conventional layout, a composer.json, and a service provider that follows Laravel conventions. Before tagging a release, review version constraints, remove ecosystem-specific stubs you do not need, and confirm README, LICENSE, and CHANGELOG are in place. Running composer validate --strict is a quick sanity check.
- Does using this generator affect my production application?
- No. The blast radius is your local filesystem plus whatever gets committed; there is no runtime footprint in the generated package. The generated code boots like any first-party Laravel package. Do keep package creation governed, though, because cheap scaffolding can produce package sprawl that a platform team then has to support.
- Is tomatophp/laravel-package-generator actively maintained, and should I pin a version?
- It has a single maintainer, a small validation surface, and best-effort issue response, with the last release noted around October 2024. Pin an exact version so upstream stub changes cannot silently alter your generated output. If you plan to depend on it long term, budget for owning a fork of the stubs.
- What problems should I watch for after generating a Laravel package?
- Common repairs include vendor and namespace prompt mismatches, inconsistent hyphen-to-StudlyCase conversion for multi-segment names, and case-sensitivity bugs that pass on macOS but fail on Linux CI. Same-day generation can also collide migration timestamps, and publish tags such as --tag=config collide across packages, while view and translation namespace mismatches usually fail silently at render time rather than at boot. Fix these inside your internal wrapper instead of by hand on every generation.
Weaver
How can I help you explore Laravel packages today?