Schema Laravel Package

Getting Started

Since there is no prior assessment, treat this as a baseline review of gosuperscript/axiom at v0.6.10.

1. Install and pin the version. Because v0.6.10 is a patch release that changes operator resolution order, pin "gosuperscript/axiom": "0.6.10" rather than floating on ^0.6 until you have re-run your own rule tests.
2. Read the operator resolution layer first. The only change in this release is in how overloads are matched ("resolve presence before equality overloads"). Before writing any rules, find the code or docs section that describes the operator/overload registry and the order in which candidate operators are evaluated. That ordering is now part of your package's observable behaviour.
3. Check the test suite for the PR. The upstream change is PR #85 (compare/v0.6.9...v0.6.10); the accompanying tests are the best specification of the new semantics — they show exactly which expression was previously resolving to an equality overload and now resolves to a presence one.
4. First use case. Start with a single, unambiguous rule that exercises both operator families, e.g. a rule that checks a field is present and a rule that checks a field equals a value, and assert both behave as expected through your application's entry point (validation rule, policy, or wherever you invoke the package). Do this before porting existing rules over.

Implementation Patterns

Wrap the package behind your own rule/decision service. Do not scatter calls to the package across controllers and form requests. A thin App\Support\Rules\RuleEvaluator (or similar) that takes a definition + payload and returns a result keeps the blast radius of future operator-resolution changes contained to one class.

Be explicit about operator intent. The whole point of v0.6.10 is that two operator families can overlap. In your own definitions and custom overloads, prefer distinct, self-describing operator names over ones that could be read as either a presence check or an equality check. Ambiguity is what the package now has to arbitrate for you — don't rely on it.

Register overloads in one place. If you extend the package with custom operators/overloads, register them in a single service provider method rather than inline. That gives you one file to audit whenever operator precedence changes (as it did here).

Test with data providers. For each rule you ship, add a table-driven test covering: field absent, field present with a null value, field present with a matching value, field present with a non-matching value. The absent/null/present distinction is precisely where presence-vs-equality resolution shows up, so these cases are your regression net.

Compile once, evaluate many times. If the package supports compiling or parsing a rule definition, do that at boot/config time or cache it — evaluate the compiled form per request. This is the standard pattern for rule engines and it also makes the resolution behaviour deterministic and inspectable.

Integrate at the boundaries you already have. Validation rules, form requests, and authorization policies are the natural seams. For validation, implement ValidationRule (or a Rule closure) that delegates to your evaluator so failures surface as normal Laravel validation messages rather than raw package exceptions.

Gotchas and Tips

• v0.6.10 is a behavioural change, not a cosmetic one. "Resolve presence before equality overloads" means an expression that previously bound to an equality overload may now bind to a presence overload. Audit any existing rule where a field could be interpreted as checked for existence rather than compared for value, and re-run your tests on 0.6.9 vs 0.6.10 to see what moved.
• Watch the null/absent edge case. Presence semantics usually distinguish "key missing" from "key present but null". Equality overloads often do not. If your payloads come from $request->validated() or $request->all(), remember Laravel will include keys with null values but omit genuinely missing ones — that difference is now semantically meaningful.
• Debug by dumping the resolved operator. When a rule misbehaves after the upgrade, log which overload actually matched rather than guessing from the result. If the package doesn't expose this, wrap the evaluation call and log the definition plus the payload shape — that's usually enough to spot a presence/equality mix-up.
• 0.6.x is pre-1.0. Patch releases can carry semantic changes like this one. Treat every bump as requiring a full test run, and avoid ^0.6 in composer.json for anything production-critical until you've pinned and verified.
• Config quirks. If the package publishes a config file, check whether operator ordering or overload enablement is configurable — a stale published config can silently override package defaults after an upgrade. Re-publish with vendor:publish --force into a diff and merge deliberately.
• Extension points worth knowing. Custom overload registration and any operator-priority setting are the two levers you have over resolution. Reach for them only after confirming the default order (presence → equality) doesn't already do what you want; overriding it re-creates the ambiguity this release was written to remove.
• Upgrade checklist. Pin 0.6.10 → run your rule tests → grep for rules involving optional fields → check logs for changed match paths → only then relax the pin.