updating your stubs<\/a> with your naming conventions. Any time your developers create new files, they will start off with your proper naming conventions in place. If a file is already using one particular naming convention, then your developers are more likely to continue to follow suit.<\/p>Simple Modifications (Basic)<\/h3>
I\u2019ve worked on a number of Laravel projects that used the SoftDeletes trait in pretty much every model. It\u2019s really easy to add soft deletes to your models, but it\u2019s also something that\u2019s really easy to forget about. Are you starting a new project where you will require records to be soft deleted in every table? If so, then I would recommend updating your model.stub<\/code> to include the boilerplate code for soft deleting records. Once you\u2019ve done that, all subsequent models created via artisan make:model<\/code> will be already equipped for soft deletion.<\/p>Some systems we\u2019ve worked on require a connection to an external API, and in some of those cases, we end up creating several files\u2014each of which interacts with a different part of the API. Oftentimes, the separate files we create will have commonalities; when we do that, we end up creating our own artisan command, which, when run, will utilize our own custom stub. Doing this can be a huge time-saver when collaborating with multiple developers. It\u2019s usually best that whomever knows the workflow and external API is the one creating the new stub and command. That way, other developers who don\u2019t yet understand the external API or workflow can get up and running with boilerplate code in a familiar Laravel way in no time.<\/p>
Overriding Artisan Make (Advanced)<\/h3>
It\u2019s even possible to override what happens when an artisan make<\/code> command is issued. Discussing how to do so is beyond the scope of this article, but I want to provide an example of how this can be used. It\u2019s pretty common for us to use artisan make:model -a<\/code>. Doing so will create a model, resourceful controller, policy, a couple of request files, a seeder, a factory, and a database migration script. We\u2019ve expanded the command to also create a couple of Vue files for us. One represents a list view for the new model, and one, a details view. Having done this, when we create a new module for a project we\u2019re working on, we can have a working (albeit simple) list and details view within a couple of minutes\u2014pretty game changing!<\/p>Wrapping Up<\/h2>
I hope you have a better understanding of what Stubs are, and what kinds of QOL improvements they can make for you and your team. Let us know how you\u2019re using them in your project, and what kind of impact they\u2019ve had for your organization.<\/p>