Taxation Bundle Laravel Package

Product Decisions This Supports

• Tax domain modeling (build vs. buy). The bundle is best read as a reference architecture, not a dependency. It shows how to separate tax categories (product tax classes), tax rates, jurisdictions, and a calculation strategy applied to line items. That decomposition is worth copying into our own thin tax abstraction regardless of vendor.
• Vendor selection groundwork. It clarifies what an in-house build would not give us: rate tables, nexus/place-of-supply logic, exemptions, invoice-grade rounding, audit trails. That gap is the business case for buying (Avalara, TaxJar, Stripe Tax, Vertex) rather than extending a package like this.
• Legacy triage. If any portfolio asset runs Vespolina/Symfony2, this is a migration decision ("what replaces this and when"), not an adoption decision.
• Framework fit. The package targets Symfony2 bundles, not Laravel. Adopting it means either a non-trivial port or pinning to an EOL framework — a hard constraint on any roadmap that includes it.
• Use cases it does not support: VAT/GST compliance, rate sourcing, cross-border rules, exemption certificates, or anything requiring an audit trail. Scope it strictly as "calculation mechanics," not "tax compliance."

When to Consider This Package

Consider (narrowly):

• You maintain a legacy Symfony2/Vespolina storefront and need to understand or temporarily stabilize existing tax behavior.
• You want a small, self-contained reference for how to model tax in a PHP domain layer — no external API calls, easy to read in an afternoon.
• You need a throwaway prototype where correctness of rates is irrelevant and you only need the shape of the calculation.

Look elsewhere (the default):

• Any production compliance need. Tax is legally binding; stale or absent rate data is a financial and legal exposure, not a bug.
• Modern stacks. Symfony 5+/6/7, Laravel, or any app with current PHP constraints — expect incompatible bundle conventions and unmaintained transitive dependencies.
• Health signals are disqualifying for dependency use: 9 stars, 0 dependents, no visible maintainer activity or CI. That combination means no upstream fixes, no security response, and no community support when it breaks.
• Scale requirements: multi-currency, rounding policies, per-invoice tax breakdowns, and reporting all need more than this provides.
• Anything where you'd have to fork it. Forking means you own it permanently — price that in, and compare against a vendor contract.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated vespolina/taxation-bundle, a small Symfony2 tax component from a dormant ecommerce project. Recommendation: do not adopt it as a dependency. It has negligible adoption (9 stars, zero dependents), targets an end-of-life framework, and carries none of the rate data or compliance logic that makes tax software valuable — so it would add maintenance and legal risk without reducing work. Instead, we should buy tax calculation from a specialized vendor and build a thin internal abstraction (tax category → rate → jurisdiction → calculator) so the vendor can be swapped. The bundle is useful only as a free design reference for that abstraction, which costs us nothing to borrow.

For engineering: Treat it as documentation, not code. Lift the separation of concerns (product tax class vs. rate vs. jurisdiction vs. calculation strategy) into our own interface, then implement it against a vendor API. Do not vendor or fork unless a legacy system forces it — and if it does, log a replacement ticket at the same time. Budget roughly a day to read it; do not budget a sprint to integrate it.

Risk framing to state plainly: compliance risk (wrong tax is a legal/financial issue), maintenance risk (unmaintained dependencies in a payment-adjacent path), and opportunity cost (effort spent porting it exceeds effort spent integrating a vendor SDK).