I was able to use like below but Iban\Validation\Validator class has the final keyword is blocking now and I can't extend anymore.

I don't need any violation list because it does not matter when one of these validations is failed.

namespace App\Service;

use Iban\Validation\Validator;

class IbanValidator extends Validator
{

    public function validate($iban)
    {
        $this->validateCountryCode($iban);
        $this->validateLength($iban);
        $this->validateFormat($iban);
        $this->validateChecksum($iban);
    }

}

Then I can handle validation issues in try catch like below.

class SomeController extends AbstractController {

    #[Route('/user/iban-review/{iban}', name: 'user-iban-preview')]
    public function previewAction(string $iban): JsonResponse
    {
        try {

            return $this->json([
                'success' => true,
                'result' => $this->ibanParser->parse(new Iban($iban))
            ], 200, [], ['groups' => ['public']]);

        } catch (Throwable $exception) {

            return $this->json([
                'success' => false,
                'message' => $exception->getMessage()
            ]);

        }

    }
}

This PR add's support for php8.

• php-cs-fixer had to be removed during build process, since it doesn't support php 8, yet
• I upgraded the phpunit.xml.dist config to phpunit 9.3 standard
• the Validator::bigIntModulo97 method had to drop it's nullable state, since phpstan correctly stated:

Method Iban\Validation\Validator::bigIntModulo97() never returns null so it can be removed from the return typehint.

When using this library, i get the following deprecation:

Not implementing the "Iban\Validation\Swift\RegistryLoaderInterface" for argument "$registryLoader" is deprecated since 1.8.1.

However, this is caused by the internal functions of this library, because they pass nothing to the Iban\Validation\Swift\Registry::__construct() function. That falls back to null, which results in the deprecation beeing triggered.

This can easily be resolved by adding an ! is_null() check to the if statement that checks for the deprecation

Hello, I found a breaking change in a project I work on using a ^1.2 version constraint where the build fails when installing v1.8 as the Iban\Validation\Swift\RegistryLoader class does not exist anymore.

• src/Swift at v1.7
• src/Swift at v1.8

Was it intentional or a refactor targetting a v2 ?

As requested by: https://github.com/genkgo/camt/pull/110#pullrequestreview-813685962

The registry loader is quite slow because it has to parse ~1200 lines of YAML before it does any validation.

So for the use case in the CAMT package, it has to create a new validator for each IBAN it encounters. (our testing file has about 700 IBAN numbers and that takes quite awhile)

My suggestion would be to use arrays instead of YAML, so it doesn't have to parse anything. What do you guys think?

Hello, I think it's interesting the funcion that you can get the bank code of an iban for example to know the bank of the account and can associate with a table of banks that you have or whatever, what do you think?

Hi,

PHP 7.4 no longer suppresses malformed input for bcmath functions. See https://www.php.net/manual/en/migration74.incompatible.php

If you try to validate the IBAN MCBKCWCU25727002 for example, the library will use BK as part of the checksum and make the call bcmod('12321230257270022212BK', '97', 0) in \Iban\Validation\Validator::local_bcmod. As you can see the first argument is not numeric and it leads to the error mentioned in the title.

When I migrate to the new iban-validation package and try to validate an iban number, I get the following error:

: Uncaught Error: Class 'Symfony\Component\Yaml\Parser' not found in lib/external/packages/symfony/yaml/Yaml.php:77 Stack trace: #0 lib/external/packages/jschaedl/iban-validation/src/Swift/RegistryLoader.php(41): Symfony\Component\Yaml\Yaml::parse('AD:\n country...') #1 lib/external/packages/jschaedl/iban-validation/src/Swift/Registry.php(37): Iban\Validation\Swift\RegistryLoader->load() #2 lib/external/packages/jschaedl/iban-validation/src/Validator.php(84): Iban\Validation\Swift\Registry->__construct() #3 lib/model/Supplier.php(40): Iban\Validation\Validator->__construct()

• copying the PHPUnit config is not necessary, PHPUnit will use the dist file by default anyway
• caching Composer files will speed up successive builds
• the --dev option is set by default on composer install
• disable the Xdebug extension to speed up the test execution
• use --prefer-dist instead of --prefer-source to speed up package installation

Welcome to Renovate! This is an onboarding PR to help you understand and configure settings before regular Pull Requests begin.

🚦 To activate Renovate, merge this Pull Request. To disable Renovate, simply close this Pull Request unmerged.

Detected Package Files

• composer.json (composer)
• .github/workflows/coding-standards.yaml (github-actions)
• .github/workflows/static-analysis.yaml (github-actions)
• .github/workflows/tests.yaml (github-actions)

Configuration

🔡 Renovate has detected a custom config for this PR. Feel free to ask for help if you have any doubts and would like it reviewed.

Important: Now that this branch is edited, Renovate can't rebase it from the base branch any more. If you make changes to the base branch that could impact this onboarding PR, please merge them manually.

What to Expect

With your current configuration, Renovate will create 2 Pull Requests:

❓ Got questions? Check out Renovate's Docs, particularly the Getting Started section. If you need any further assistance then you can also request help here.

This PR has been generated by Mend Renovate. View repository job log here.

As discussed in #53, this PR will add support for php 8 on the 1.x branch. I had to change the Symfony dependencies, since there were some php 8 compatibility fixes in the mentioned versions.

Good morning, sir, Super IBAN verification library :) however do you know a library that allows via the iban to retrieve the BIC code? Or do you have in the future idea of developing this feature?

And is there a possibility to retrieve only the key and not the error message? I use a custom rule in Laravel for IBAN checking and I would like to be able to return only the key of the error message so that I can translate it later in several languages.