Introduction
I recently tagged and released two new versions (v2.0.0 and v2.1.0) of one of my packages, Laravel Config Validator. So, I thought I'd put together a Quickfire post to give a quick overview of what has been added and changed.
What is Laravel Config Validator?
If you haven't already heard of Laravel Config Validator, here's a quick rundown of what it is and why you might want to use it in your Laravel projects...
Towards the end of 2020, I built the package mainly as a proof-of-concept. The intention of the package was to provide developers the ability to define rules for your Laravel app's config so that you could validate the fields.
My main motivation for this package was that I'm regularly being onboarded to new projects as a freelancer. So, each time I pull down a project to my machine to start working on it, I need to make sure that I have all the correct config and environment variables set up. For example, let's say that the app requires API keys for making HTTP requests to an API. By using Laravel Config Validator, I could define a rule to ensure that the keys are set correctly and in the right format. If a developer wanted to get really fancy, they could also write their own custom rule to make an API call so that they can 100% certain that the config values are working with the API.
To give this a bit of context, let's imagine that your code interacts with the Mailchimp API and so you have a services.mailchimp.api_key config field like so:
config/services.php1return [2 // ...3 4 'mailchimp' => [5 'api_key' => env('MAILCHIMP_API_KEY'),6 ],7 8 // ...9];
If we didn't provide a key in our .env field for the MAILCHIMP_API_KEY, it's probably very likely that we would only find out that the key was required or is incorrect when our application actually tries to interact with the Mailchimp API. So, by using Laravel Config Validator, we can write a set of rules that we can run before the application ever tries to interact with the API. For example, we could write the following set of rules (making the assumption that the ValidMailchimpKey rule makes a call to the Mailchimp API to ensure that the keys are actually valid.
config-validation/services.php1use AshAllenDesign\ConfigValidator\Services\Rule;2use App\Rules\ValidMailchimpKey;3 4return [5 Rule::make('mailchimp.api_key')6 ->rules(['required', 'string', new ValidMailchimpKey()]),7];
Now that we've added this rule, we could run the command php artisan config:validate in our terminal. If the services.mailchimp.api_key field is valid, the validation will pass. Otherwise, errors will be shown to indicate what is wrong with it.
And the best part is that you don't need to learn any new syntax! Under the hood, the package uses the Validator provided by Laravel. So, you can use the same rules that you would typically use in your request validation.
Using Termwind for Command Output
Thanks to a really cool contribution from Francisco Maderia, as of v2.1.0, Laravel Config Validator now uses Termwind for the output in the validation command. This means that instead of the validation errors being output in a table, they're now using some awesome CLI styling.
Here's a look at how the failure output for the command used to look before v2.1.0:
And, here's how the failure and success output for the command now look thanks to the new Termwind additions:
I'm sure that you'll agree that the newer output looks a lot cleaner than before!
Major Bug Fixes
Laravel Config Validator v2.0.0 fixes two bugs that were present in earlier versions of the package.
1. Caching Bug
Before v2.0.0 of Laravel Config Validator, your config rules would be stored in a config/validation folder in your project. My original thinking behind this was that it would make logical sense to keep the validation for the config inside the config folder, so then it would be grouped together.
However, due to me being a bit naive, I never took into consideration what would happen when running php artisan config:cache. When running this command, it would also try and cache the validation rules, which would inevitably cause the command to crash and the config to not be cached.
So, as of Laravel Config Validator v2.0.0, the default location for the config isn't config/validation anymore, and is now config-validation instead. By moving the validation rules out of the config folder, you can now run the config:cache command without the package interfering.
2. Using Rule Objects
In earlier versions of the package, you weren't able to use rule objects in your validation. For example, you couldn't have a config validation ruleset like so:
config-validation/services.php1use AshAllenDesign\ConfigValidator\Services\Rule;2use App\Rules\ValidMailchimpKey;3 4return [5 Rule::make('mailchimp.api_key')6 ->rules([new ValidMailchimpKey()]),7];
Trying to use a rule object (like the ValidMailchimpKey rule) would throw an exception. However, as of v2.0.0, you can now use your own rule objects to write more complex config validation checks. For example, you might want to write a rule that makes an API call to Mailchimp to make sure that the calls are actually valid and can be used as expected.
Laravel and PHP Version Changes
As of v2.0.0, the package no longer supports PHP 7.3 or PHP 7.4. This means that your project will need to be using either PHP 8.0 or PHP 8.1.
Support for Laravel 6 and 7 has also been dropped; meaning that your project will need to be using either Laravel 8 or Laravel 9.
By dropping support for older PHP and Laravel versions, it allows us to make use of newer features in the language and framework when adding new features.
Migrated from Travis CI to GitHub Actions
Like many of my older projects, when I originally created the package, I added a CI workflow that would run the PHPUnit tests when a pull request was made. But, over time, I've been moving away from Travis CI for running my workflows and have been slowly migrating over to GitHub Actions.
My reason for migrating is that it allows me to consolidate all the moving parts and bring them on to one platform that's easier to manage. So, although this doesn't necessarily affect any developers using any of my packages, by moving my packages over to GitHub Actions, it makes maintenance easier for myself.
There's also a cool new Larastan workflow that also runs on each pull request so that it makes it easier to maintain a good quality of code and hopefully spot bugs before merging new code.
Tidying Up
As part of the v2.0.0 release, I also took the chance to add type hints and return types to the package. I'm a huge fan on return types and type hints because I love the extra protection that it can provide for us as developers. On a side note, if you're interested in type safety, check out my "Type Safe Package for PHP" blog post about a proof-on-concept package that I made that you can use to add better type safety to your PHP projects.
I also moved the default validation rule stubs that come with the package from the config-validation folder to a stubs/config-validation folder. I feel that this makes more logical sense and if anymore stubs are added in the future, it will be easier to group them all together.
Conclusion
Hopefully, this post should have shown you the new changes that have been made to Laravel Config Validator v2.0.0 and v2.1.0.
If you enjoyed reading this post, I'd love to hear about it. Likewise, if you have any feedback to improve the future ones, I'd also love to hear that too.
If you're interested in getting updated each time I publish a new post, feel free to sign up for my newsletter below.
Keep on building awesome stuff! 🚀