Code Generator Laravel Package

Getting Started

Treat this as a local-development scaffolding tool, not a runtime dependency. The reality check has not changed: 0 stars, 0 dependents, and now pre-1.0 at v0.1.2 — the code is the documentation. The release cadence implied by a jump from a stable-looking 1.0.0 assumption to v0.1.2 tells you the API surface is actively moving; anything you build on top should be removable in one commit.

Minimal steps

composer require --dev jtc-solutions/code-generator:^0.1.2
php artisan vendor:publish --provider="JTC\CodeGenerator\CodeGeneratorServiceProvider"

Verify the exact provider namespace and publish tags from the package's composer.json (extra.laravel.providers) and its README before running the publish command. With a package this small and this young, the provider class name and publish tags are the two things most likely to differ from your assumption. If auto-discovery is enabled you can skip manual provider registration.

Where to look first, in this order

1. README.md — usually the only usage doc; expect it to be terse, and expect it to lag the release by at least one version.
2. src/Console/ (or src/Commands/) — the artisan signatures reveal every available option and argument, which is more reliable than the README, especially with v0.1.2's new service/repository options.
3. src/Generators/ or equivalent — with services and repositories now in scope, the generator classes are the real spec. Look for how nullable properties and DTO variants are handled.
4. config/code-generator.php after publishing — namespaces, output paths, stub locations, and now the controller parent override.
5. resources/stubs/ or stubs/ — the templates that determine what you actually get. With the new single-DTO change, this is the place to confirm exactly what a generated Create vs Update path looks like.
6. composer.json — check the require block for the Laravel version constraint and any new dependencies pulled in by the services/repositories additions (e.g. a container or repository abstraction package).

First use case

The highest-value entry point is still turning an existing migration into a working vertical slice, but the slice now goes deeper: model + request(s) + controller + service + repository + routes. Design your migration first (columns, indexes, foreign keys, nullable/non-nullable), run it, then generate. Schema-first generation now feeds even more downstream code — nullable columns should produce nullable properties in the model and correct ?type hints in the service/repository signatures, which is exactly the bug class v0.1.2 addresses.

A safe trial: create a throwaway posts table in a scratch branch with at least one nullable column and one foreign key, generate against it with services and repositories enabled, and diff the output against what you'd have handwritten. The nullable column is the cheap regression test for the new feature; the foreign key tells you whether the repository generator understands relations or just does raw attributes.

Implementation Patterns

Schema-first CRUD scaffolding, now with layering

The dominant workflow remains migration → generate → customize, but the surface is larger. Generated code should still be treated as a first draft that saves keystrokes, never code of record. Commit generated output as its own commit, then a "handwritten adjustments" commit — the separation matters more now because there's more to adjust (model, request, controller, service, repository, routes).

php artisan migrate
php artisan code:generate --table=posts --with-service --with-repository  # confirm exact flags from src/Console

Repository and service generation is opinionated — pick a side

The new service and repository generators are the single biggest decision v0.1.2 introduces. The repository pattern is not universal in Laravel; a lot of teams deliberately skip it in favour of Eloquent + query objects or the action pattern. Before enabling --with-repository, decide whether your codebase already has a repository convention. If it does, this is a genuine time saver — the generated repository becomes a thin, consistent wrapper you'd have written anyway. If it doesn't, you are adopting an architectural pattern from a 0-dependent package, and that is a much larger commitment than adopting a scaffold tool. Either use the repository generator everywhere or don't use it at all; mixed conventions age badly.

Publish and own the stubs — now including service and repository stubs

The most important integration step is unchanged and more valuable than ever: publish stubs into your app and edit them to match house style. With v0.1.2 the stub set is broader (model, request, controller, service, repository, routes). Once stubs live in your repo, the package becomes a thin templating engine and the generated code stops looking foreign. This is also your escape hatch if upstream is abandoned — you keep the stubs, you keep the output.

Configure the controller parent

Ability to configure parent for Controllers is a small but high-leverage addition. Point it at your app's App\Http\Controllers\Controller (or a domain base controller) so generated controllers pick up your middleware, auth traits, and shared helpers without a manual edit pass. Do this before generating anything real — it's the cheapest way to make generated controllers feel native.

Unified DTO for Create and Update — the workflow change

v0.1.2 changed to a single DTO for Create and Update controllers. Practically: generated code now has one request/DTO class handling both verbs, rather than two. This reduces boilerplate but means update-specific validation rules (e.g. unique:posts,slug,{id}, sometimes|required) need a guard inside the DTO. If you already generated controllers pre-v0.1.2, be aware regenerating will change the DTO shape and likely break your controller references — treat this as a breaking change within the 0.x line, not a silent improvement. If you want the two-DTO pattern back, that's a stub edit.

Environment-gated usage

Because generated code lands directly in app/, guard against accidental execution outside development. Install with --dev, never let this into a production deploy pipeline, and never let it run in CI where a stray command could overwrite real source. This advice is unchanged and more important now that a single invocation writes more files.

Pair with the rest of the Laravel toolkit

Generated migrations → php artisan db:seed + factories. Generated controllers → feature tests you write yourself. Generated services and repositories → unit tests if you rely on them. The generator gets you to a working vertical slice fast; the tests are what make the scaffold trustworthy. Practical rhythm: generate, write one feature test per generated endpoint, refactor freely knowing the contract is pinned.

Team workflow

Put the stub directory under code review like any other source. When a new resource shape appears (polymorphic relation, soft deletes, nullable audit columns), update the stubs once and regenerate. If two developers are hand-editing generated files in divergent ways, the generator is adding cost — that's your signal to fix stubs or drop the tool.

Gotchas and Tips

The supply-chain reality, sharpened by v0.1.2

Still 0 stars, 0 dependents. The new release reinforces the risk profile rather than reducing it: pre-1.0 versioning means breaking changes ship as minor bumps, and the "single DTO" change proves it — pre-1.0 packages can and do reshape their output between patch-level releases. Concretely: pin the exact version ("jtc-solutions/code-generator": "0.1.2", not ^0.1), vendor the stubs into your repo, and accept that you may be maintaining a fork. The new service/repository generators likely pull in additional require entries — check composer.json before installing, since a small generator gaining a repository-abstraction dependency is a supply-chain surface you didn't ask for. Before adopting, verify the release date against your Laravel version; generated code targeting a slim skeleton (Laravel 11/12 with no app/Http/Kernel.php, casts() method instead of $casts) may still be wrong if the stubs predate the framework change.

The DTO change is a breaking change, even at 0.1.x

If you generated anything against v0.1.0/v0.1.1, do not run the generator over those files expecting a clean diff. The Create/Update split was replaced by a unified DTO, so regenerating will:

• produce a single DTO file where you previously had two,
• leave your controllers pointing at a DTO class that no longer exists (or now handles both verbs).

Plan: regenerate into a clean branch, diff, and manually port the update-specific validation logic into the new unified DTO using conditional rules ($this->isMethod('put') / route-parameter-aware Rule::unique(...)->ignore(...)). If you have more than a handful of generated resources, consider pinning to 0.1.1 until you've scheduled the migration; the stub edit to reintroduce two DTOs is small, but that just moves the maintenance to you.

Overwrite semantics

The most common failure mode for any generator is a careless re-run clobbering hand-edited files, and v0.1.2's broader output (service + repository + DTO) means more files at risk per invocation. Before your first real run, determine empirically: does the command overwrite, skip, or prompt? Test on a file you've modified. Many generators have a --force flag that is off by default — verify that default holds. Keep generation on a clean working tree so git diff is your undo button, and ideally run it in a throwaway branch even after you trust it.

Namespace and path assumptions

Generators typically hardcode App\Models, App\Http\Controllers, App\Services, App\Repositories, and database/migrations. Two new wrinkles in v0.1.2: the service and repository namespaces are almost certainly configurable but may have their own keys, and the controller parent override is likely its own config key (e.g. controllers.parent). If your app uses domain namespaces (App\Domain\Blog\Models), expect either a config key for each base namespace or a stub edit for each. Check config/code-generator.php for namespace, paths, and parent blocks before assuming it's unsupported.

Nullable properties — verify rather than trust

The "nullable properties" addition is easy to assume works. Cheap verification: generate against a table with a nullable string column and a nullable integer foreign key, then check (1) the model's property docblock/type is ?string / ?int, (2) the DTO/request rules() uses nullable, and (3) the service/repository method signatures preserve nullability. Generators frequently fix the model and miss the downstream layers; if you find nullability dropped in the repository layer, that's a stub edit, not a bug report you'll get traction on.

Config caching bites

If you publish config and then edit it, run php artisan config:clear. A cached config from a previous run is the most common reason "the setting didn't take" — and with the new controller-parent and service/repository namespace keys, it'll bite immediately. Same for composer dump-autoload after install if artisan doesn't see the new command, and after a version bump since command registration can move between releases.

Debugging a silent generator

If the command exits clean but nothing appears, check in this order: (1) -v / -vvv for the resolved output path per artefact; (2) whether the table name is being pluralized/singularized unexpectedly; (3) whether stub files are present at the configured path (publish sometimes only copies config, not stubs — and if the new service/repository stubs weren't published, generation may fail silently or produce stubs from the package's vendor/ directory, which defeats your house-style edits); (4) file permissions on each target directory (app/Services, app/Repositories may not exist yet and the generator may or may not create them); (5) whether the DTO change left your controller referencing a class that no longer gets written.

Extension points worth knowing

The realistic extension surface is still: custom stubs (high value, low risk), config-driven namespaces/paths/parent (medium, and now more of it), and subclassing the generator command (only if the package exposes non-final classes and protected methods — inspect before relying on it). Don't build a deep abstraction on top of a 0-dependent package; keep your integration shallow so removal is a composer remove and a stubs deletion, not a refactor. The v0.1.2 service/repository additions tempt you toward a deeper integration ("our whole service layer is generated"), which is precisely the wrong way to use this package.

Verdict for day-to-day use

Worth a trial if your team writes a lot of similar CRUD, you already use (or want to standardise on) a repository/service layering, and you're willing to own the stubs. The v0.1.2 additions meaningfully broaden the use case — the vertical slice now covers a genuinely architectural pattern, not just boilerplate — but that also narrows the audience: teams that deliberately avoid the repository pattern should skip this release or use it with services/repositories disabled. Not worth it if you have strong existing conventions, use a first-party alternative (make: commands plus Livewire/Inertia generators, or an established scaffold like Laravel Nova/Filament generators), or if the Laravel version constraint doesn't match your app. The opportunity score still hovers around the low-to-mid 20s: real utility, now with a more opinionated footprint, offset by pre-1.0 instability and a crowded field of better-supported alternatives. Pin the version, fork the stubs, and treat every minor bump as a potential breaking change until 1.0.