If one are using this package to validate postal codes, then there is a good chance, that one is using a country code validation package like for example the laravel-validation-rules/country-codes package

Problem 1: Invalid country code

If one is sending two fields like this:

use LVR\CountryCode\Two;

Validator::make([
    'country' => 'XX',//invliad country
    'postal_code' => '12345789',
], [
    'country' => ['required', new Two],
    'postal_code' => 'required|postal_code:country'
]);

Then the validation rule is throwing an InvalidArgumentException exception since the country XX is unknown. The problem is that this is already handled by the new Two rule, so it’s unfortunate that the user gets a HTTP 500 error.

Problem 2: Unsupported country code

Let’s assume that a country YY exists, but is not supported by this package.

If one is sending two fields like this:

use LVR\CountryCode\Two;

Validator::make([
    'country' => 'YY',//assume a valid country that is just not supported by this package
    'postal_code' => '12345789',
], [
    'country' => ['required', new Two],
    'postal_code' => 'required|postal_code:country'
]);

Then the validation rule is throwing an InvalidArgumentException exception since the country YY is unknown to the package. There might be use cases where would like a logic that is more like only fail for countries supported by the package and assume valid for unsupported countries.

Suggestion 1: Don’t throw exceptions

I suggest that instead of throwing an InvalidArgumentException the we simply return false. That way validation will fail, but the customer will see that the

Suggestion 2: Add a new rule only for supported countries

If we add a new rule postal_code_only_supported:country which returns false for invalid postal codes in supported countries and true for valid postal codes in supported countries + true for any postalcode in unsupported countries.

With this new rule and the existing rule, then we can support all use cases.

What do you think @axlon?