Technical Evaluation

Architecture fit

Single-purpose, dependency-free PHP library that parses and evaluates mathematical expression strings without eval(). That matters in a Laravel codebase where the alternative is usually a hand-rolled eval() shim buried in a service class.
Fits as a leaf utility, not an architectural component: stateless, no I/O, no framework coupling. It slots in behind an application-owned interface (e.g. ExpressionEvaluator) rather than being called directly from controllers or models.
Realistic fit is narrow: pricing/discount rules, formula fields, KPI/dashboard calculated metrics, configurable tax or fee logic, and admin-defined scoring models. If the product has no user- or admin-authored formula surface, this package has no reason to be in the dependency graph.

Integration feasibility

composer require chriskonnertz/string-calc and a container binding; no service provider, no config publishing, no migrations. Effort is measured in hours, not sprints.
The work is not the library — it is the governance wrapper: input length caps, allowed-character/grammar allowlist, exception-to-domain-error mapping, result caching, and audit logging of who submitted which formula.
Because it is framework-agnostic, it is equally usable in queue workers, Artisan commands, and HTTP paths, which simplifies the design.

Technical risk

Security (medium): no PHP code execution, but user-supplied expressions remain an untrusted input surface. Deeply nested parentheses or pathological terms are a CPU-exhaustion vector. Mitigate with length/depth limits, execution timing guards, and synchronous-only invocation on bounded inputs.
Precision (medium): floating-point arithmetic for money is a defect generator. If the expressions touch currency, results must be rounded and validated at the domain boundary, not trusted raw from the evaluator.
Abandonment (high): last release 2022-05-13, ~102 stars, effectively single-maintainer. Assume no upstream fixes. This is the dominant risk and drives the wrapper-first design.
Behavioral gaps (medium): unclear/undocumented handling of division by zero, very large exponents, locale decimal separators, and unsupported function names. These become production incidents unless enumerated and tested up front.

Key questions

Is any expression input user-, tenant-, or admin-authored, or are all terms developer-authored constants? (If developer-authored, most risk evaporates.)
Does the business require functions beyond + - * / ( ) — min/max, rounding, percentages, variables, unit handling? The library's grammar coverage must be confirmed against the actual formula spec before commitment.
What is the precision and rounding contract for monetary expressions, and where is it enforced?
Do we need deterministic, reproducible audit of a computed value (store the term + library version + result)?
Is the PHP/Laravel version matrix of the current stack inside this package's supported range, and has it been verified rather than assumed?

Integration Approach

Stack fit

Composer-native, zero transitive dependencies, MIT — trivially compatible with a Laravel project structure and with CI dependency scanning (nothing to conflict with).
Laravel adds no value here: no facade, no auto-discovery, no config. Treat it as a plain PHP library and expose it through one application-owned service so the vendor type never leaks past that boundary.

Migration path

Wrap first, adopt second: define ExpressionEvaluator (interface) with a StringCalc implementation and a fake for tests. This makes the package replaceable in one file if it is abandoned or outgrown.
If an existing eval()-based calculator exists, migrate by running both implementations in parallel (dual-write/compare) on production terms, diffing results before cutover. Any result divergence is a spec question, not a bug report.
Backfill: persist computed values rather than recomputing historical figures, so a library upgrade cannot retroactively change reported numbers.

Compatibility

Verify PHP constraint and test against every PHP/Laravel minor in the supported matrix; a 2022 release predates recent PHP minors and should be treated as unverified until CI proves otherwise.
Pin to an exact version in composer.json and lock it. Do not allow float within a major if the package ever resumes releasing.
Confirm locale behavior explicitly: force . as decimal separator at the input boundary and normalize before evaluation.

Sequencing

Spike (1–2 days): enumerate the real formula grammar required by the product; confirm the library covers it; write a 20-case conformance test including adversarial inputs.
Build the wrapper + limits + exception mapping + tests; no product code calls the library directly.
Ship behind a feature flag for one bounded use case (e.g. a single discount rule type).
Instrument: log every evaluation failure, every limit trip, and p95 evaluation latency.
Expand surface only after one quarter of stable production evidence; otherwise hold and reassess.

Maintenance

Low ongoing cost, but no upstream maintenance to rely on. Budget for ownership: a named maintainer, a vendored fork policy, and a documented decision to fork if a PHP minor breaks it.
Upkeep is mostly the wrapper and its conformance tests, which are cheap and portable — the real asset is the test suite, not the dependency.

Support

No vendor, no SLA, no security channel. Community-only via GitHub issues on a low-activity repo. Escalation path is "we patch our fork."
Internal support burden is low if the wrapper is good: most tickets will be "my formula is wrong" (user error / grammar gap), not "the library is broken." Ensure error messages returned to users are domain-readable, not raw parser exceptions.

Scaling

Purely in-process and CPU-bound; horizontally scales with the app, no external dependency to saturate. Fine for per-request single evaluations and short batch loops.
Do not put it in a hot path over large collections (e.g. evaluating a formula per row across 100k rows in a report). Precompute and persist, or cache term → result keyed by normalized expression.
Watch queue workers: a pathological expression on a synchronous endpoint is an availability risk; enforce timeouts and input caps at the boundary.

Failure modes

Malformed expression → exception. Must map to a 422-class domain validation error, never a 500.
Division by zero / overflow / non-finite results → confirm and codify behavior; reject rather than propagate INF/NAN into persistence.
Precision drift → wrong money. Highest-severity failure because it is silent; requires rounding-contract tests in CI.
Resource exhaustion from adversarial nesting → request timeout and worker starvation.
Abandonment → a future PHP upgrade breaks the package with no upstream fix. Mitigated by the interface wrapper and a fork playbook.
Silent semantic change on version bump → mitigated by exact pinning plus stored results.

Ramp-up

Near-zero for a PHP developer: one class, one method. Half a day to productive, one day to understand the wrapper's constraints.
The non-obvious learning is organizational: engineers must internalize that the grammar is a product surface. Changes to allowed operators, functions, or rounding are user-visible behavior changes requiring the same review as an API change.
Given the low opportunity score (1.89) and a three-year-old last release, position this as a tactical, contained utility — approved for one or two bounded use cases with the wrapper in place, not as a platform capability or a dependency to build a product strategy on.