Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Laravel Taxify Laravel Package

omaralalwi/laravel-taxify

Laravel Taxify adds flexible tax calculation to Laravel apps. Define tax rates, apply inclusive or exclusive taxes to prices, and compute totals for carts, invoices, and orders through a clean, configurable API. Supports multiple rates and jurisdictions.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

The package is a Laravel-native tax calculation library, likely delivered as a service provider plus facade/helper APIs and configuration for rates and calculation behavior. Architecturally it fits Laravel monoliths, APIs, and commerce backends that need reusable tax calculation without building a full tax engine. It is best treated as a calculation component behind an application-level tax adapter, not as the system of record for tax compliance.

Integration feasibility is high for teams already on Laravel: Composer installation, config publishing, and service invocation are standard. v2.0.4 is a patch release that enhances returned numbers through rounding behavior. That is a small API surface change but a material financial-correctness change: tax outputs may differ by minor units from v2.0.3. Technical risk is therefore low from an integration perspective but elevated from a financial regression perspective. Key risks include rounding mode ambiguity, tax-inclusive vs tax-exclusive handling, multi-currency precision, jurisdiction/rate configuration, and whether historical calculations remain reproducible.

Key questions for the maintainer or internal spike: Which Laravel and PHP versions are supported? Is rounding mode configurable, and what changed exactly in v2.0.4? Does the package support tax-inclusive pricing, multi-currency, and jurisdiction-specific rules? Are rates stored, cached, or externally sourced? What test coverage exists for rounding edge cases? Does the package persist calculations or only return values? What is the upgrade policy for minor/patch releases?

Integration Approach

Stack fit is strong for Laravel applications using Eloquent, queues, and API resources. The package can support carts, invoices, quotes, and order calculations where tax is computed inline or via a service layer. It is less suitable as a standalone replacement for enterprise tax-compliance platforms if the business needs nexus determination, exemption certificates, filing, or complex cross-border rules.

Migration path from v2.0.3 to v2.0.4 should be treated as a controlled patch upgrade: pin v2.0.4, run composer update in a branch, and execute regression tests against representative carts, invoices, discounts, refunds, and multi-currency scenarios. Compare v2.0.3 and v2.0.4 outputs at the minor-unit level. No structural migration is expected, but configuration and cached rate data should be verified.

Compatibility checks should confirm PHP version, Laravel major version, database support if migrations exist, and interaction with existing pricing, discount, and currency packages. Sequencing: first validate the package in a non-production environment with production-like tax scenarios; then add an internal adapter/facade boundary; then run finance/accounting acceptance tests on rounding; then deploy to staging and monitor calculation deltas; finally release to production with a rollback pin to v2.0.3 if financial outputs diverge unexpectedly.

Operational Impact

Maintenance is likely low at the package level, but ownership of tax rules, rate updates, and rounding policy remains internal. Support impact is moderate because finance and customer-support teams may escalate minor-unit discrepancies. v2.0.4 specifically warrants a support note: returned values are rounded differently, so reported tax totals may shift by small amounts.

Scaling is generally favorable because tax calculation is compute-light; the main scaling concerns are database reads for stored rates, cache invalidation when rates change, and avoiding per-request external tax calls. Failure modes include rounding drift, misconfigured rates, missing jurisdiction coverage, currency precision loss, tax-inclusive/exclusive mistakes, and regressions after patch upgrades. Ramp-up is low for Laravel developers and moderate for finance stakeholders who must validate outputs. Recommend an internal adapter, golden-case regression suite, configurable rounding policy, and explicit finance sign-off before production rollout.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
diephp/sequences
users-au/socialite-provider
twidpay/twid-logger
mrnewport/laravel-plaid
mrnewport/laravel-repo
mrnewport/laravel-docsign
mrnewport/laravel-stow
mrnewport/laravel-flow
mrnewport/laravel-priceable
mrnewport/laravel-nestedterms
fredmeng/laravel-apidoc-generator
itstructure/laravel-multilingual-tools
pdustdar/elasticsearch
markupai/php-sdk
rlacerda83/lumem-microservice-shipment
uni-method/symfony-lib
tacticmedia/scim-server-bundle
neika-ai/symfony-bundle
mattleads/agent-publishing-bundle
glavweb/framework-bundle