cubeta/cubeta-starter
Cubeta Starter is a Laravel package that scaffolds new projects with sensible defaults, bundling authentication, configuration, and common utilities. It speeds up setup by providing reusable starter code and conventions for building PHP applications.
Cubeta-Starter is a Laravel CRUD scaffolding package with a browser GUI. You describe a resource (table + columns), it generates the model, migration, controller, requests, routes, and Blade views from stubs. Think "Artisan make: commands with a form and preview," not a runtime admin panel.
Minimal setup:
# Prefer a dev dependency so the GUI never ships to production
composer require --dev cubeta/cubeta-starter
# Publish config (and any stubs/assets the package tags)
php artisan vendor:publish --provider="Cubeta\Starter\CubetaStarterServiceProvider"
# Confirm the GUI route the package registered
php artisan route:list | grep -i cubeta
Then start your app (php artisan serve) and open the route the package registers (typically /cubeta-starter, sometimes env-gated). If you get a 404, check the published config for a route prefix and an enabled/environments flag.
Where to look first: the published config/cubeta-starter.php. It tells you the route prefix, which envs expose the GUI, stub paths, and generation targets. Read that before touching the GUI — it answers 80% of "why didn't it appear / where did the file go."
First use case: scaffold one small, boring resource end-to-end (e.g. categories with name, slug, is_active). Generate it, run php artisan migrate, hit the generated routes, and read every generated file. That single pass tells you the package's conventions — naming, namespace layout, validation style, view structure — which is the real thing you're adopting. Only then decide whether it's worth using on a real feature.
Greenfield scaffolding, then hand-editing. The productive loop is: generate → review the diff → migrate → customize. Treat generated output as a first draft committed in its own commit so the diff is reviewable and revertible. Do this per resource, not in one giant batch.
Retrofitting existing tables. Point the generator at an existing table name and let it infer columns, then discard the migration and keep the model/controller/views. This is often the highest-value use: you already have the schema, you just want the boilerplate. Verify inferred types (especially json, enum, decimal, nullable FKs) before trusting generated validation rules.
Core vs dev dependency is a real architectural decision.
--dev: GUI and generation code never load in production. This is the default you want. The tradeoff is that composer install --no-dev in CI/deploy removes it, so any runtime code that depends on the package will break.require, not --dev): only justified if you actually need package classes at runtime (e.g. a base controller or trait you extend). In that case, explicitly gate the GUI route in config by environment so it isn't publicly reachable.Pick one and encode it in the README so the next developer doesn't composer require it back into core "to fix" a missing route.
Team workflow. Because generation is deterministic-ish from stubs, commit customizations to stubs and config rather than hand-tweaking every generated file. That way a second resource generated next month matches the first. If the package supports custom stub paths in config, override there — it's the cleanest extension point and survives package upgrades better than editing vendor files.
Compose with your own conventions. If your app has base classes (App\Http\Controllers\Controller extensions), FormRequest base classes, or a resource/API convention, adjust the stubs once so every generated resource inherits them. Generated code that ignores your base classes creates cleanup work on every resource — fixing stubs amortizes it.
Pair with migrations you control. Generate into a fresh branch, run php artisan migrate:fresh --seed locally to validate the generated migration, then squash/adjust before merging. Don't let generated migration filenames collide with existing ones.
git diff is your safety net.APP_ENV, the published config's environment list, and php artisan route:list. Clear cached config (php artisan config:clear) after publishing — a stale config cache is a classic "I published it but nothing changed."$this->authorize(...) / policies), unique constraints, and cross-field rules manually — generators rarely get these right.composer.json, and when something misbehaves, vendor/cubeta/cubeta-starter/ is the source of truth — stubs and the generator service are small enough to read in minutes. Budget for the possibility you fork it or vendor the stubs.--dev, never use a package class in app code that runs in production; it'll fatal on --no-dev installs. Keep the dependency one-directional: the package generates your code, your code doesn't import the package.vendor/ is a last resort and will be wiped by the next composer update.composer install is the most common first-day stumble with tools like this.Bottom line: worth a timeboxed trial on a throwaway resource to see if its conventions match yours. If they do, it saves real time on repetitive CRUD. If they don't, the stub-customization cost may exceed the savings — and with low adoption, weigh that against the maintenance risk of depending on it at all.
How can I help you explore Laravel packages today?