Formulate Laravel Package

Technical Evaluation

Architecture fit. rezzza/formulate is a framework-agnostic PHP utility for composing and evaluating math formulas, not a Laravel package in the conventional sense — expect no service provider, facade, config file, or published migrations. Architecturally that is fine: it belongs behind an application-owned interface (e.g. FormulaEvaluator) in the domain or a dedicated calculation service, bound in a service provider. The risk is that the package's value proposition is narrow enough that the adapter is often thicker than the dependency it wraps.

Integration feasibility. Composer-installable, MIT-licensed, no transitive weight. The real blocker is provenance: last release 2016-05-17 places it in the PHP 5.6/7.0 era. Before any spike, inspect composer.json for php and illuminate/* constraints and confirm whether the source uses constructs removed in PHP 8 (each(), curly-brace string offsets, untyped signatures that now clash with strict callers). A composer why-not against the target Laravel version is the cheapest possible go/no-go test and should be run before anything else.

Technical risk — high. Three compounding factors: (1) abandoned upstream with ~12 stars means no security response, no PHP 8.x compatibility work, and effectively zero peer review of the parsing logic; (2) math evaluation libraries frequently reach for eval() or create_function() internally, which is a code-injection vector the moment any part of the formula originates from user input — this must be confirmed by reading the source, not assumed; (3) floating-point precision behaviour is almost certainly undocumented, which is disqualifying for billing, pricing, or tax calculation use cases. Score 0.28 with a nine-year-old release is consistent with "works in a demo, untested in production."

Key questions for the maintainer/sponsor.

• Does evaluation use eval(), create_function(), or a hand-rolled parser? Is the grammar closed or extensible?
• Is the package a builder (emits an expression string) or an evaluator (returns a value)? The risk profile differs enormously.
• What is the target PHP and Laravel version, and has anyone in the team run the test suite on it?
• Is there an existing business requirement that symfony/expression-language cannot satisfy?
• Who internally owns this if upstream goes dark permanently (it already has)?

Integration Approach

Stack fit. Treat it as a leaf dependency, never a core primitive. Define an internal interface, implement it with a thin FormulateAdapter, and bind it in a service provider so the underlying library is swappable without touching call sites. Keep formula strings out of the persistence layer where possible; store structured inputs and render the expression at evaluation time.

Migration path. Do not adopt directly into main. Run a timeboxed spike (1–2 days) in a throwaway branch that installs the package, runs the upstream test suite on the target PHP version, and exercises two or three representative real-world formulas. If it passes, vendor it: fork to an internal namespace, pin the exact version, and add PHP 8 compatibility patches. If it fails or requires more than a day of patching, switch to symfony/expression-language — actively maintained, first-party Symfony (thus idiomatic in Laravel), sandboxed evaluation, and a documented grammar. For anything monetary, pair either option with brick/math rather than relying on native floats.

Compatibility. Verify explicitly against the actual runtime matrix: PHP version, Laravel version, and any Octane/Swoole considerations (static state in an expression parser is a classic source of cross-request leakage). Check for namespace collisions with existing Math/Formula helpers and confirm the license file ships with a valid MIT header.

Sequencing.

1. Source audit (eval usage, PHP 8 readiness, precision handling) — gate.
2. Spike + upstream test suite run on production-equivalent PHP — gate.
3. Adapter interface and service provider binding merged before the dependency, so the abstraction exists independently.
4. Build-vs-buy decision recorded in an ADR with the audit findings attached.
5. If adopted: fork, pin, CI the fork, and document the escape hatch to symfony/expression-language.

Operational Impact

Maintenance. You are the maintainer. Upstream has been silent since 2016; there is no release cadence, no deprecation notices, and no one to escalate to. Budget the fork as a real line item — a few hours per PHP minor upgrade, more if the parser needs touching. This is the single largest cost driver and it is invisible until the first PHP upgrade after adoption.

Support. Effectively none. No vendor, no active issue triage, no CVE monitoring. Add the fork to the internal dependency register so security scans flag it, and ensure the team knows there is no upstream patch path.

Scaling. Parsing and evaluation are CPU-bound and cheap per call, but three things matter at volume: cache compiled/parsed expressions rather than re-parsing per request; cap expression length and nesting depth to bound worst-case evaluation time; and if the library uses eval(), expect it to interact badly with OPcache and to defeat static analysis. For high-throughput paths, benchmark against a precompiled alternative before committing.

Failure modes. Expect silent precision drift on decimal arithmetic (the most dangerous failure — no exception, wrong number); DivisionByZeroError or an equivalent uncaught error on edge inputs; parse failures surfacing as generic exceptions that are hard to map to user-facing validation; deprecation warnings escalating to exceptions under Laravel's error handler; and, if formula input is user-supplied, denial-of-service via pathological expressions. Mitigate with input validation at the boundary, a closed grammar, explicit decimal handling, and exhaustive tests on boundary cases.

Ramp-up. The API surface is small, so initial velocity is fine — the cost is elsewhere. New engineers will find no documentation, no examples beyond a sparse README, and no Stack Overflow corpus. Institutional knowledge concentrates in whoever ran the spike. Mandate an internal README covering the grammar subset you actually use, the precision contract, and the swap-out procedure, or that knowledge walks out the door with the original adopter.