As of version 7.16.0, Laravel Homestead supports a canonical file for this purpose. I’ve written about the user-customizations.sh
file for Homestead here.
Since joining Liquid Web, I’ve gotten to revisit Laravel, my favorite application framework for PHP. I’m still doing plenty of WordPress work, of course, but when building web applications — especially those with robust APIs — building atop Laravel makes so much more sense than shoehorning it into a WordPress environment.
In their mission to make application development delightful, Taylor Otwell and the other Laravel developers (including my friend Joe Ferguson) maintain Laravel Homestead, a pre-packaged Vagrant box for Laravel development. While the environment can be installed globally (in the way you might use VVV for WordPress development), Laravel Homestead can also be installed on a per-project basis, ensuring each application has its own, dedicated virtual machine.
Since we may have multiple developers working on any given application, I’m a huge fan of the per-project installation, which simplifies development environment setup to:
1 |
$ composer install && php vendor/bin/homestead make |
I’ve also recently gotten into the habit of adding an alias to my composer.json
file:
1 2 3 4 5 6 7 |
{ "scripts": { "homestead": [ "@php vendor/bin/homestead make" ] } } |
This lets developers who want to leverage Laravel Homestead to run composer homestead
following composer install
for an even easier setup process.
What happens when I install Laravel Homestead?
Running composer homestead
creates a Homestead.yml
in the local directory (don’t worry, it’s already blocked from being committed via the .gitignore
file). The Homestead.yml
file contains settings local to your Homestead instance, including hostnames, folder mapping, and resources allocated to the virtual machine.
Laravel Homestead’s installation procedure also generates an after.sh
script that, when present, will execute additional provisioning steps. This is extremely helpful if your application has dependencies that aren’t bundled in the default Homestead image (for example, RabbitMQ).
Customizing Laravel Homestead on a per-developer basis
After using Homestead on a few separate apps, I noticed a pattern — every time I provisioned the box, I’d have to go through the same steps over and over:
- Change the default editor from Nano to Vim
- Set my name and email address in the local Git configuration
- Configure Git to use the “simple” push strategy (so it stops bugging me)
These are settings that not every developer who works on the project will want (especially if their name isn’t “Steve Grunwell”); as a solution, I’ve started using the after-local.sh
pattern:
1 2 3 4 |
# Load developer-specific after.sh commands. if [ -e after-local.sh ]; then sh ./after-local.sh fi |
Adding that bit to the end of after.sh
instructs the setup script to look for the presence of and after-local.sh
file (use whatever filename makes the most sense for your team) and, if it exists, execute it. For example, my after-local.sh
file looks like this for Liquid Web projects:
1 2 3 4 5 6 7 8 9 |
#!/bin/sh sudo update-alternatives --set editor /usr/bin/vim.basic git config --global push.default simple # But, you know, with a real email address git config --global user.name Steve Grunwell git config --global user.email sgrunwell@example.com |
Finally, add after-local.sh
to your project’s .gitignore
file, and your development team is now free to customize a Laravel Homestead box according to their preferences without forcing those decisions on every other developer!
Leave a Reply