- How do I install Laravel TurboMaker in a Laravel application?
- Install it with Composer using composer require grazulex/laravel-turbomaker, then let Laravel's package discovery register the service provider. Publish the configuration and stubs with the vendor:publish command so you can adjust generator defaults. After installing, confirm that the required grazulex/laravel-modelschema ^1.3.1 dependency resolves cleanly in your lockfile before running any generators.
- Which Laravel and PHP versions does laravel-turbomaker support?
- TurboMaker follows standard Laravel service-provider and dependency-injection conventions, so it targets current Laravel releases on supported PHP versions. Check the package's composer.json for the exact PHP and Laravel constraint matrix before adopting it, since the schema generation path also depends on grazulex/laravel-modelschema ^1.3.1. Run the same PHP version in your CI image and deployment containers that you test locally to avoid surprises.
- What files does the TurboMaker CRUD command generate in a single run?
- A single command can scaffold a complete feature stack: the model, migration, controller, routes, form requests with validation, API resources, views, factories, and seeders. That means you skip writing boilerplate by hand and get a consistent structure across features. Generated artifacts land wherever your published configuration points, so review that output path before running the command in an existing project.
- Can I customize the generated stubs, templates, and validation rules?
- Yes. TurboMaker ships publishable configuration and stub templates, so you can edit them to match your naming conventions, namespaces, and directory layout. Because the stubs drive the generated form requests, resources, and validation, customizing them keeps every future scaffold consistent with your project style. Commit your published stubs to version control so teammates and CI generate identical code.
- Why does generateAll() behave differently or fail after upgrading to v2.5.1?
- In v2.5.1 the ModelSchemaGenerationAdapter now calls the real ModelSchema GenerationService instead of returning simulated results. That means genuine execution, real file I/O, and hard failures when a generator produces no fragments, which can break CI pipelines that previously relied on simulated success. Treat the release as a new functional capability rather than a drop-in patch: update in a branch, refresh the lockfile, clear cached config, and test against representative schemas.
- Do I need grazulex/laravel-modelschema installed to use TurboMaker?
- For the schema-driven generation path, yes, the adapter depends on grazulex/laravel-modelschema ^1.3.1 and will not produce real output without it. Pin that dependency in your composer.json and verify that version 1.3.1 reports generation success the way the adapter expects. If you only use the basic Artisan CRUD generators, confirm which code paths your commands actually touch before assuming the dependency is optional.
- How should I test TurboMaker scaffolding and generation in CI?
- Add an integration test that runs generation against representative model schemas and asserts on the actual files and fragments produced, rather than mocking a simulated response. Run it in a non-production environment with the same PHP extensions and filesystem permissions as your deployment target. Gate your pipeline on that test so a generator returning no fragments fails loudly instead of silently shipping incomplete artifacts.
- Is laravel-turbomaker a runtime dependency I should use in production request paths?
- No. TurboMaker is a developer tooling and scaffolding package, so invoke it from Artisan commands, queued jobs, or CI steps rather than inside HTTP controllers. Calling generateAll() during a request adds filesystem I/O and runtime cost, and a hard failure would surface directly to users. Keep generation isolated behind an application service or build step and review generated artifacts before they reach production.
- How do I publish the TurboMaker config and control where generated files are written?
- Use Laravel's vendor:publish command to copy the package configuration and stubs into your application, then adjust the output paths, namespaces, and generator settings there. Because the adapter now writes real files, ensure the target directories exist and are writable by the process running the command. In CI and containers, verify filesystem permissions and consider backups or a clean working tree so partial generation is easy to inspect and roll back.
- What are the alternatives to Laravel TurboMaker for CRUD scaffolding?
- Laravel's built-in make: generators cover single files, while dedicated scaffolding packages such as Blueprint or generator suites offer fuller CRUD stacks with their own stub systems. TurboMaker's differentiator is its Turbo-charged command set plus schema-driven generation through laravel-modelschema, so compare on stub customization, dependency footprint, and whether you need real schema generation in CI. Whichever you choose, pin versions and test generation output in a branch before rolling it into your workflow.