Uvdesk App Creator Laravel Package

Getting Started

This is a scaffolding package, not a runtime dependency — its whole job is to spit out a directory tree you then own and edit. Treat adoption as a one-off tooling decision rather than an architectural one.

• Install as a dev dependency. composer require --dev it, and pin the exact version ("0.1.0") rather than a caret range. At v0.1.0 there is no meaningful compatibility promise, and a scaffolding tool that changes its output shape between patches will silently produce inconsistent skeletons across your team.
• Look at the console command first. Open the package's src/ and find the command class (typically under Commands/ or Console/) plus any stubs/ or Resources/ directory. The stubs are the documentation at this stage — reading them tells you exactly what files, namespaces, and placeholders you'll get faster than any README will.
• Confirm what "app" means here. UVDesk is a Symfony-based helpdesk, so the skeleton this generates is most likely a Symfony bundle/app structure, not Laravel's ServiceProvider + routes/web.php + config/ conventions. Before you invest time, generate one skeleton into a scratch directory and read the output. If it doesn't match your target, this package is the wrong tool regardless of how clean the generator is.
• First use case: run the generator once against a throwaway path, diff the result against your existing project layout, and decide whether the delta is small enough to hand-reconcile. Do this before committing anything to a real repo.

Implementation Patterns

One-shot generation, then own the code. The healthy workflow is: generate into a clean directory, commit the result as a single "scaffold" commit, and never run the generator against that path again. This keeps history readable and makes it obvious which files are machine-authored versus hand-written.

Generate into a namespace you control. Most skeleton generators accept a name/namespace/vendor argument. Always pass an explicit one instead of relying on prompts or defaults — it keeps output deterministic and means two developers running the same command get byte-identical trees.

Use it as a template multiplier. The genuine day-to-day value is when you need the same skeleton more than once — multiple UVDesk apps, or a plugin-per-client pattern. Generate, strip the sample code down to your house style, then keep that stripped copy as your real internal starting point and stop invoking the package.

Wire it into a bootstrap script, not a docs page. If onboarding involves "run this command with these three answers," put it in a composer script or a shell script in the repo so the invocation is version-controlled and reviewable. Interactive console prompts are the enemy of reproducibility.

Bracket the generated output with your own checks. Add the generated directory to whatever static analysis you already run (PHPStan/Psalm, Pint or php-cs-fixer) so the skeleton is normalised to your standards immediately, rather than becoming a permanently un-linted corner of the codebase.

Bridge deliberately if you're staying in Laravel. If the skeleton is Symfony-flavoured and you need it inside a Laravel app, isolate the adapter work: one service provider that registers the pieces, one config file mapping the skeleton's assumptions onto Laravel's container and autoloading. Keep that bridge in a small, well-named namespace so the generated code stays otherwise untouched and re-generatable in spirit.

Gotchas and Tips

• v0.1.0 means "no guarantees." A one-line release note is a signal: expect missing flags, unhandled edge cases, and output-shape changes in 0.1.x. Pin the version and vendor-lock your decision in a short ADR or README note so nobody upgrades casually.
• Name collision risk is real. "UVDesk apps creator" is a generic-sounding name; verify the Composer vendor/package you're installing is the one you think it is, and check the repo's activity. Abandoned scaffolders are common and cost more than they save.
• Interactive prompts break in CI and in Docker builds. If the command uses question()/ask() style prompts, it will hang or take defaults non-interactively. Test with --no-interaction; if it's unsupported, don't put it in any automated path.
• Overwrite behaviour is the classic failure mode. Check what happens when the target directory already exists. Assume it may overwrite without warning until proven otherwise: generate into a temp path and move files yourself.
• Non-TTY debugging: run with maximum verbosity (-vvv) and watch which paths get written. If the command fails silently, the most common cause is a missing writable parent directory rather than a logic bug.
• Autoloading is the first post-generation error. A fresh skeleton almost always needs a composer dump-autoload and possibly a new PSR-4 entry before anything resolves. Add that to the bootstrap script.
• Extension points are likely thin. At this version, don't expect a documented stub-override or config-publish mechanism. Read the command class: if stubs are read from the package's own vendor/ path with no publish step, your only customisation route is forking the package or generating-then-editing. Prefer the latter — it keeps you off a fork you'll have to maintain.
• Reassess on 0.2.0. If a release note ever mentions stub publishing, config publishing, or non-interactive flags, that's the point to reconsider automating the workflow rather than treating generation as a manual one-off.