- Can I use sparkling/vat-bundle in a Laravel application?
- No. sparkling/vat-bundle is a Symfony 2 bundle distributed with a DI extension and AppKernel registration, not a PSR-4 library that Laravel can autoload and bind. Laravel has no bundle kernel hook, so the delivery format is incompatible. The only reusable part is the thin VIES SOAP call logic, which would need a rewrite behind your own interface.
- Does sparkling/vat-bundle have a Laravel ServiceProvider or facade?
- No. There is no ServiceProvider, facade, config publishing, or container binding, so the Laravel-native integration surface is entirely absent. In Symfony it is wired through a bundle class registered in AppKernel plus XML or YAML service definitions. Using any of it in Laravel means porting those services yourself.
- Why does Composer fail when I install this package in a Laravel project?
- The bundle is pinned to Symfony 2.x components while Laravel requires modern symfony packages at v6 or v7. Composer cannot co-resolve both sets in one dependency graph, so the install fails before any code runs. That conflict is usually fatal and is the quickest way to evidence the decision to not adopt it.
- What does sparkling/vat-bundle actually do?
- It validates European VAT numbers through the VIES service using SOAP, wrapped in Symfony validators and services. The genuinely reusable capability is small: take a country code and VAT number, call VIES, and return validity. Everything else is Symfony 2 wiring that does not transfer to other frameworks.
- Is sparkling/vat-bundle still maintained?
- No. The last release was 2018-09-11 and the repository is archived. It has roughly 26 stars and zero dependents, meaning no third party is known to run it in production. There is no active security monitoring, CVE coverage, or community support, so treat it as documentation rather than a dependency.
- What PHP version does this bundle require?
- The code targets the PHP 5.x and 7.0 era, and Symfony 2 reached end of life in 2018. Running it on PHP 8.1 or later requires patching the source, at which point you are no longer using the package as published. Modern Laravel applications should not depend on it.
- Is this bundle safe to use for EU VAT compliance and reverse-charge invoices?
- It carries high risk. EU VAT validation underpins B2B reverse-charge treatment and invoice validity, and auditors expect evidence of validation at the time of supply plus controlled change management. An archived dependency on a tax-determination path will likely fail change-control and audit review on its own merits, regardless of whether the code still runs.
- Does it handle VIES downtime or unavailable member states?
- Not in any documented, reliable way. The bundle predates current VIES behaviour and does not answer the real product question: block the sale when VIES is unavailable, or accept the order and queue it for later verification. That decision belongs in your own domain layer, not in an abandoned bundle.
- What is the best alternative for VAT validation in Laravel?
- Define a small domain contract of your own, for example a VatValidator interface returning a result object with status (valid, invalid, unavailable, format error), a consulted-at timestamp, and the member state consulted. Implement it against the current VIES REST endpoints using Laravel's HTTP client and persist evidence for audit retention. You can also evaluate maintained VAT validation packages, but keep the interface owned by your codebase.
- What is the relationship between sparkling/vat-bundle and ruudk/VATBundle?
- The brief names sparkling/vat-bundle while the upstream repository is ruudk/VATBundle, which suggests a third-party fork or repackaging. If that is the case, ask who maintains it and what the delta from the archived upstream is. Adopting an unattributed fork of an archived Symfony 2 bundle compounds the risk.