Product Decisions This Supports
- Build vs. buy for a formula engine. This package is a commodity "string in, number out" evaluator. The decision it informs is whether expression parsing is a differentiator for your product (almost never) or a utility you should vendor in an afternoon and move on from.
- Roadmap for configurable business logic. It unblocks the recurring ask: "let admins change the pricing/shipping/commission formula without a deploy." That is a real product capability — a rules field in an admin panel, a formula column in a report builder, a quote/estimating calculator — and this library is the smallest possible enabler of it.
- Scope discipline on "Excel-in-a-textbox" features. It supports arithmetic with parentheses and operator precedence only. If product asks for variables, named functions, conditionals, or cell references, that is a different (larger) workstream — decide that now rather than discovering it mid-sprint.
- Feature-level risk acceptance. Adopting it is a decision to accept a low-activity, single-maintainer dependency (102 stars, last release May 2022, no indexed repository) in exchange for ~zero integration cost. Frame it as a leaf dependency: safe if isolated behind your own small wrapper interface, risky if called directly from twenty places.
- Prioritization signal. Low opportunity score (1.89) confirms expression evaluation is a solved, undifferentiated problem. Do not fund a bespoke parser; spend the roadmap budget on the authoring experience (validation, previews, error messages) that users actually judge you on.
When to Consider This Package
Adopt when:
- The input is semi-trusted — admin-authored formulas, internal config, template-level expressions — not arbitrary end-user input from the open internet.
- The math is simple: integers, small decimals, parentheses,
+ - * /. If the domain is money, keep amounts in integer minor units or wrap the result in a decimal library rather than trusting float output.
- You have no variables, no functions, no conditionals, and don't expect them within a release or two.
- Footprint matters (CLI tools, shared hosting, legacy PHP) and you want a dependency-free, MIT-licensed, few-hundred-line library you could read and fork in an hour.
- You need it now for a low-blast-radius feature and can wrap it behind an internal
ExpressionEvaluator interface so swapping it later is a one-file change.
Look elsewhere when:
- You need variables, functions, comparisons, or logic — reach for
symfony/expression-language (maintained, extensible, well-documented) instead of bolting features onto this.
- Precision is contractual: money, tax, commission, invoicing. Use
brick/math for the arithmetic and treat parsing as the easy half.
- The expression source is untrusted or user-generated at scale — you need sandboxing, resource limits, and a maintenance commitment this project cannot evidence.
- You're on a modern PHP line (8.3+) and need a dependency with an active security response and a release cadence you can cite in a vendor review.
- The "Repository: unknown" result isn't a data gap but reality — that's a supply-chain finding, and it should stop adoption in a regulated or audited environment until verified.
How to Pitch It (Stakeholders)
To executives (one paragraph): "We have a recurring request to let customers and admins define their own calculations — pricing tiers, shipping rules, commission formulas — without engineering involvement. There's a small, free, permissively licensed PHP library that parses and evaluates arithmetic formulas, so the first version of that capability is roughly a week of integration rather than a quarter of custom work. It's a utility, not a platform bet: we wrap it so it can be replaced, we keep it out of anything touching billing precision, and we accept that it's a lightly maintained open-source component rather than a vendor product."
To engineering (the pitch and the caveats in the same breath): "Use it for internal, semi-trusted arithmetic. Put it behind our own ExpressionEvaluator interface, add input length and character allow-listing before evaluation, coerce inputs to integers or decimal-safe values, and write tests against precedence and unary minus. Do not use it for money without a decimal layer. Budget one spike to confirm PHP-version compatibility and check whether the upstream repo is genuinely unmaintained — if it is, we fork it internally at trivial cost and own the 200 lines."
The honest one-liner if asked to justify the score: "Low score, low risk — it's a commodity parser. We're buying two days of work, not a relationship. The decision that matters is the interface we put around it, not the library itself."