We've already covered the ways Valet allows you to use Valet itself to make changes to its dependencies, but what we have not covered is a Valet-approved way to make configuration changes to those dependencies, but you have to actually make the changes yourself. So let's take a look. There are two different ways to make these kind of configuration changes to Valet's dependencies. The first configuration option is when there's an open directory and you can add as many configuration files as you want there, and they'll all be red. So let's take a look. You can see this with dnsmasq.d. Anything you put in here will be loaded to dnsmasq as a configuration file.

You can see this with dnsmasq.d. Anything you put in here will be loaded to dnsmasq as a configuration file. So you can see in here we've got the default tld-test.conf, where we actually tell dnsmasq how to configure the .test domain. Just says .test should go to 127.0.0.1. And then we also have tld-buzz.conf, because at some point I tested out using .buzz as a tld. But any other files we put in here would also be loaded by dnsmasq. For example, my friend Chris Brown, or Dr. Byte, who you've probably seen around on the Valet forums, uses custom dnsmasq files to block certain ad networks.

For example, my friend Chris Brown, or Dr. Byte, who you've probably seen around on the Valet forums, uses custom dnsmasq files to block certain ad networks. He showed me his blockamazonads.conf file that just says any requests to these particular domains should be routed to 0.0.0.0, which means they get blocked. So we can just copy this file right here. You can create a new blockamazonads.conf, paste it in, and now that configuration is sent over to dnsmasq next time it restarts. You can also have loose configuration files when you're configuring PHP. You're probably familiar with the php.ini file, but if you're not, every single installation at PHP has a configuration file, and any time you have to add something with Peckle or any

You're probably familiar with the php.ini file, but if you're not, every single installation at PHP has a configuration file, and any time you have to add something with Peckle or any other specific configuration things, you edit that ini file. The problem is you now have a massive file with all the pre-built-in configuration items that would live there by default, and then your one specific config is also just there with everything else. Instead, you can create custom.ini files, and PHP will load them for you. You'll just go to the /etc/php/conf.d directory for that particular version of PHP, and any files in here that end in .ini will just be loaded. So you can see we've got phpmemorylimits.ini, and this sets memory limits in here so you

files in here that end in .ini will just be loaded. So you can see we've got phpmemorylimits.ini, and this sets memory limits in here so you can set them separately, but you can also just do any other configuration items you want, for example, adding a particular dependency by just adding that here. And anything you put in here will just be automatically loaded by PHP. The other way to make custom configurations like this is to edit the stub files that Valet uses to generate all of its individual files. Every single time you install dnsmasq or phpfpm or nginx, either globally for Valet or specifically for one particular site, it's going to pull the configuration files that it uses for those from its local stubs.

or specifically for one particular site, it's going to pull the configuration files that it uses for those from its local stubs. We've looked at those before as we looked into the Valet vendor directory, but you can actually choose to essentially publish those stubs and make modifications to them, and then every single time Valet is spinning up a new site or reinstalling itself, it'll instead pull from those customized stubs that you edited. For example, if we go to phpfpm.d instead of conf.d, you've got this valet-fpm.conf file, and this configures all of the pool information that we're talking about, including memory limits, how many workers you're having, how many children the worker is going to have, and sometimes you might want to modify these things because you might want it to use more

memory limits, how many workers you're having, how many children the worker is going to have, and sometimes you might want to modify these things because you might want it to use more children or more servers or whatever else. So if you wanted to make changes to this particular file, you could, but then the next time anything happens that publishes this file, it's all going to get overwritten unless you edit stubs. So what you need to do to edit a stub is figure out what the name of the stub is originally, and then copy that into ~/.config/valet/stubs directory. The easiest way to do this is to go to the Valet directory and search for the particular stub you're looking for.

The easiest way to do this is to go to the Valet directory and search for the particular stub you're looking for. For example, I know it's going to be phpfpm.conf, and there's that same file, but this is the stub version. As you can see, it's got certain things here named valet-user and valet-homepath that will be replaced by our script when we publish it. So if we grab this stub file right here and make a version with this exact same file name in that local directory, then any changes you make in here will be picked up by Laravel the next time it needs to publish a phpfpm file. This is a more common situation if you want to customize the server directives for nginx.

the next time it needs to publish a php-fpm file. This is a more common situation if you want to customize the server directives for nginx files. If you take a look at valet.conf, this is the nginx configuration file, and if you wanted to make any modifications to the server blocks for all of your nginx sites, you can do it here. You can also do it just for the secure ones, or the secure proxied ones. So if you look through the code for Valet, any single time it looks for a stub, it's actually going to be using this method called getStub, which looks for that exact same stub first in your local stubs directory, and then its own dependency directory, so you can publish

actually going to be using this method called getStub, which looks for that exact same stub first in your local stubs directory, and then its own dependency directory, so you can publish that stub file to your local directory, make any modifications to it that you want, and Valet will work with that in the future. If you wanted, you could even put this stubs directory under version control, and bring your stubs from project to project with you. So that's my last set of tricks for using Valet. I hope you learned a ton, and had a great time doing it. See you later!

See you later!