Math Biginteger Laravel Package

Product Decisions This Supports

• API identifier strategy: 64-bit vs. 128-bit IDs. Decides whether the product can accept/store IDs beyond PHP_INT_MAX (Snowflake-style IDs, Twitter/Discord-style snowflakes, third-party order or transaction references) without silent float coercion. This package lets you prototype that path in pure PHP before committing to a schema or an extension dependency.
• Build vs. buy vs. bundle for numeric primitives. A cheap reference implementation for evaluating whether a custom bigint helper is worth writing, or whether the platform's native BCMath/GMP is sufficient. It informs a "do we own numeric correctness?" conversation.
• Environment/deployment constraints as a roadmap input. Pure-PHP implementation matters only if the target hosting environment cannot enable ext-gmp or ext-bcmath — common on cheap shared hosting, some legacy PaaS images, and locked-down enterprise PHP builds. If that segment is in scope, it is a real (if temporary) enabler; if not, it is dead weight.
• Ledger, loyalty, and balance features. Informs whether point balances, wallet credits, or high-precision counters need arbitrary precision at all, or whether integer-cents in BCMath is the correct, cheaper answer.
• Cryptography and token surface. Relevant to any roadmap item touching RSA key handling, signature verification, or base62/base58 encoding of large numeric IDs — areas where a wrong-precision primitive becomes a security or data-integrity incident, not a bug.
• Tech-debt and dependency-risk scoring. A useful calibration point: an archived, ~22-star library with no maintainer is a liability on the roadmap, not a foundation. Feeds directly into your dependency-approval policy and your "no unmaintained packages in the critical path" rule.

When to Consider This Package

Consider only when all of the following hold:

• You genuinely cannot enable BCMath (bundled and enabled by default in essentially all standard PHP builds) or GMP — not "it's inconvenient," but "the host contract forbids it."
• The workload is low-volume and non-latency-sensitive; pure-PHP bignum math is roughly one to two orders of magnitude slower than the C extensions.
• The use is transitional — a spike, a migration shim, a one-off data backfill — with a dated exit plan.
• You are prepared to vendor it, pin the version, and read the source. There will be no upstream fixes.

Look elsewhere in almost every other case:

• ext-bcmath / ext-gmp — the default answer. Native, fast, maintained by php-src, present in standard builds.
• brick/math — the modern, actively maintained, well-tested PHP arbitrary-precision library with BigInteger, BigDecimal, and BigRational. This is the correct replacement for greenfield work; it is what this package should have become.
• phpseclib/phpseclib (BigInteger) — if the actual need is cryptographic, this is the maintained descendant of the same lineage, with security handling this package never had.
• Money-specific libraries (e.g., moneyphp/money) — if the real requirement is currency arithmetic, a bigint primitive is the wrong abstraction and you will rebuild rounding rules badly.
• Database-side arithmetic — DECIMAL/NUMERIC columns plus BIGINT handle most "we need big numbers" requests with no application-layer library at all.

Hard disqualifiers: anything PCI-, payment-, or auth-adjacent; anything with an SLA; anything you would have to explain to an auditor. An archived dependency in a money or crypto path is an automatic no.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a small, free (MIT), pure-PHP math library for very large numbers. The important fact is that it is archived and unmaintained — it gets no security patches and no bug fixes. That makes it useful as a short-term prototyping aid and unsuitable as a permanent dependency in anything customer-facing or money-related. Recommendation: do not adopt as a platform dependency; if a team needs it for a constrained environment, time-box it and fund the migration to a maintained alternative.

To engineering leadership: It solves a narrow, real problem — arbitrary-precision integers without the GMP or BCMath extensions. That scenario is rarer than it used to be, since BCMath ships enabled by default. Where the constraint is real, the modern choice is brick/math (maintained, tested, same PHP-only tradeoff) or phpseclib for crypto. Cost to trial is trivial — an afternoon of vendoring and a benchmark — so the decision is cheap to make and cheap to reverse, provided we agree the exit criterion up front.

Ask: Approve a short evaluation spike against brick/math as the default recommendation, and record "archived dependencies are barred from payment, auth, and ledger paths" in the dependency policy. No budget required; the risk of not deciding is that someone quietly pulls this into a critical path because it was the first search result.