Web Generator Laravel Package

Getting Started

• Install the package with Composer (composer require savannabits/web-generator) and run php artisan vendor:publish to expose any config, stubs, or migration assets. Check config/web-generator.php (or similarly named file) first — that's where paths, namespaces, and the Vue/sidebar targets are configured.
• Discover the entry points with php artisan list | grep -i generator. v7.0.0's headline is a single "Model → Controller → Repository → Route → views → Vue → components → Sidebar Menus" pipeline, so look for the aggregate command that kicks off the whole chain rather than running each stage individually.
• First use case: scaffold one small CRUD resource end-to-end (e.g. a Post model) against a throwaway branch. That single run tells you more about the package than the docs will: which files it touches, where it places Vue components, and how it registers sidebar entries.
• Diff everything. Commit a clean tree before your first generation and inspect git status afterwards. The value proposition of this package is that it writes many files across layers — you want to know exactly which ones before trusting it on a real feature.
• Confirm your stack matches. The generator assumes a specific frontend layout (Vue components plus a sidebar menu structure). If your app doesn't use that layout, adjust the published stubs and config paths before generating, not after.

Implementation Patterns

• Scaffold-then-edit, never regenerate. Treat the generator as a one-shot bootstrapper: generate the resource, immediately review and adapt the output, then stop using the generator for that resource. Re-running over modified files risks overwriting your work.
• Use it as a consistency tool, not a productivity multiplier on day one. The payoff comes when you generate several resources in a row and get identical structure, naming, and routing conventions for free. Establish your project's conventions, bake them into the published stubs, then generate.
• Customize stubs as the primary extension point. Rather than patching generated output repeatedly, fork the stub templates so every future generation matches your team's controller/repository/request style, your test scaffolding, and your component conventions.
• Layer-by-layer migration path. If a full-stack generation is too invasive, use the package for the backend half (Model, Controller, Repository, Route) and hand-write the frontend, or vice versa. The pipeline described in v7 is sequential — check whether stages are individually invocable and lean on that during incremental adoption.
• Pair it with form requests and policies. Generated controllers typically come with basic validation; wrap the generated resource with FormRequest classes and policies early so authorization and validation don't get bolted on later.
• Sidebar/menu registration is a shared touchpoint. Multiple generated resources all append to the same menu definition. Generate resources in small batches and review the menu file between runs to catch duplicate keys, ordering problems, or namespace drift.
• Keep generation inside a PR. Generate on a branch, review the diff like any other code, and land it through normal review. This keeps the "the generator wrote it" output subject to the same standards as hand-written code.

Gotchas and Tips

• The release note is a tagline, not a changelog. v7.0.0 describes the end-to-end workflow but gives no migration guidance. Before upgrading from a v6.x install, read the actual diff on the repo, check the CHANGELOG.md, and re-publish config/stubs — a major version bump on a generator almost always means stub and config changes, and stale published stubs will silently produce outdated code.
• Re-publish and diff stubs on upgrade. Run vendor:publish --force on a scratch branch, diff the published stubs against yours, and port your customizations forward. Skipping this is the most common way generator output drifts from your conventions after a major release.
• Namespace and path assumptions break quietly. Generators that touch models, controllers, repositories, routes, views, and Vue components in one pass have a lot of hardcoded assumptions. If your app uses non-default namespaces or a src/ layout, verify config values before the first run — failures often show up as files written to the wrong place rather than as errors.
• Watch for silent overwrites. Test on a dirty tree deliberately (once, in a sandbox) to learn the package's overwrite behavior. Some generators prompt, some skip, some clobber. Knowing which one applies here determines whether you ever dare run it against a live resource.
• Frontend build coupling. Vue components and sidebar entries usually require recompiling assets (npm run dev/build) before changes appear. If generated components "don't show up," check the build step and the component registration path before digging into the generator.
• Route registration order matters. Generated routes appended to a large route file can be shadowed by earlier wildcard routes. After generating, confirm the route resolves with php artisan route:list --path=<resource>.
• Debugging strategy: generate with the smallest possible resource name and a single field, then inspect each layer in dependency order — migration, model, repository, controller, route, view, component, menu. When something's wrong, the first broken layer usually explains the downstream mess.
• Don't let it own your domain logic. The repository and controller output will be generic CRUD. Business rules, transactions, events, and authorization belong in hand-written code layered on top; keep generated files thin so regeneration (or manual re-application of a stub change) stays cheap.