Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Jsonpath Laravel Package

softcreatr/jsonpath

A fast, eval-free JSONPath implementation for PHP 8.5+. Query arrays, objects, and ArrayAccess/traversables with unions, slices, wildcards, filters, regex, and deep equality. Includes tokenized parsing and internal caching.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

Architecture fit: Still strong, and 2.2.0 makes the fit more deliberate. The opt-in JSONPath::RFC9535 mode separates "standards-compliant querying" from "legacy behavior," which maps cleanly onto Laravel's layered architecture: legacy mode for existing service/controller code, RFC mode for new middleware and validation layers where strictness matters. findPaths() returning normalized RFC result paths is the most architecturally interesting addition for a TPM—it enables provenance, audit logging, and mapping matched nodes back to source documents, which is otherwise hand-rolled in most Laravel JSON pipelines. Eager type validation and content-independent rejection of invalid queries mean expressions can be validated at config/boot time or inside a Laravel validation rule without needing a representative document, which is a better fit for form requests than the previous parse-then-evaluate model. Integration feasibility: High and improved. Composer installation is unchanged, no framework hooks required, and mode isolation means adoption is per-call-site rather than all-or-nothing. The package can now be wrapped behind a JsonPathService that pins an explicit mode, making the dependency swappable and the semantics explicit. The compliance suite (715 pinned cases checking values and normalized paths together) gives us a credible reference implementation to test our wrapper against—previously we would have had to write that harness ourselves. Technical risk: Materially reduced on the two biggest unknowns from the last assessment. Test coverage is no longer an open question: 100% CI-enforced coverage, a pinned external compliance suite, retained compatibility tests, and added regression coverage for mode isolation and nested absolute queries. The "behavioral break on upgrade" risk is largely retired because RFC semantics are opt-in and existing calls retain previous behavior. Residual risks: (1) license remains NOASSERTION—still the only risk that can block a release outright; (2) low adoption (~164 stars) means bus-factor exposure persists despite the engineering investment; (3) the future-dated release timestamp from 2.1.0 is still unexplained and should be verified against the registry, not the notes; (4) a dual-mode API is a long-term liability—two semantics to document, test, and eventually deprecate; (5) no performance data for the RFC mode, where eager validation adds per-parse cost; (6) PHP/Laravel version support still unconfirmed in the notes. Key questions:

  • Can the license be resolved to MIT/Apache? This is now the top blocker—everything else has improved.
  • Is the 2026 release timestamp a registry artifact, and what is the actual 2.2.0 publish date?
  • What are the PHP and Laravel version constraints in composer.json? Eager type validation may require newer syntax than 7.4.
  • Will legacy (non-RFC) behavior be deprecated, and on what timeline? We need a deprecation policy before we standardize on either mode.
  • What are the semantic differences between legacy mode and RFC9535 mode for the same expression? "Existing calls retain previous behavior" implies divergence—we need a documented diff to know which call sites should migrate.
  • Are findPaths() normalized paths stable and ordered deterministically for duplicate matches? Downstream audit/logging consumers will depend on it.
  • Are the RFC 9485 PCRE resource limits configurable, and what are the defaults? Unchanged from last review.
  • What is the parse/validate cost of RFC mode versus legacy mode on representative payloads, and is there a compiled-expression cache?

Integration Approach

Stack fit: Ideal for Laravel API projects doing dynamic JSON querying, and now defensible for untrusted input: RFC mode's content-independent rejection of invalid queries plus I-Regexp limits make it usable inside middleware and form requests without bespoke sanitization. findPaths() fits audit trails, webhook routing tables, and diffing payloads across versions. Migration path: Unchanged for existing code—nothing forces a move. New code should adopt RFC mode explicitly rather than inheriting the default:

  1. Wrap the package in a JsonPathService that requires an explicit mode argument (no implicit default) so semantics are visible at every call site.
  2. Pin to ^2.2, cache parsed/validated expressions keyed by mode + expression string.
  3. Migrate existing expressions to RFC mode deliberately, one call site at a time, using the compliance-suite-validated behavior as the reference; expect some legacy expressions to be rejected.
  4. Adopt findPaths() where normalized output paths are needed (logging, provenance, response shaping). Compatibility: Nominal semver-minor with explicit backward compatibility for existing calls—lower risk than 2.1.0's type-checker tightening. The real compatibility question is no longer "will the upgrade break us" but "which mode are we on," and that is a documentation and code-review problem, not a runtime one. PHP/Laravel floor still needs verification from composer.json. Sequencing:
  • Phase 1: Upgrade to ^2.2 with no behavior change; add the explicit-mode wrapper; confirm legacy paths still pass.
  • Phase 2: Stand up our own regression harness modeled on the 715-case compliance suite to pin expected behavior of expressions we rely on.
  • Phase 3: Move read-only/response-shaping call sites to RFC mode; use findPaths() for provenance where useful.
  • Phase 4: Move untrusted-input validation in middleware to RFC mode, after benchmarking parse cost and confirming PCRE limit behavior.
  • Phase 5: Eloquent JSON column usage only if native whereJsonContains/whereJsonLength prove insufficient.

Operational Impact

Maintenance: Improved and now credible. CI-enforced 100% coverage, a pinned external compliance suite, PHP CS Fixer as sole style tool, and retained compatibility tests describe a maintained project with real guardrails—this is the single largest change from the prior assessment. Counterweight remains: small contributor base, so assume bus-factor risk and keep the option to vendor or fork. New maintenance line item: tracking RFC 9535 errata and the package's legacy-vs-RFC divergence. Support: Still no commercial support. Escalation is upstream issues only. Mitigation unchanged: encapsulate behind our own facade with the mode pinned, so we can swap to json-path/json-path (more stars, older Goessner draft) if the project stalls or licensing blocks us—accepting a semantics change if we do. Scaling: Parse plus eager validation is now an explicit up-front cost in RFC mode, predictable but not free—cache compiled expressions at boot or in a keyed cache, never per request on hot paths. I-Regexp with PCRE resource limits bounds adversarial CPU, which is a scaling win, but defaults must be reviewed so legitimate large-payload matches aren't silently truncated. findPaths() on high-cardinality documents (many duplicate matches) is a new output-volume consideration for logging pipelines. Failure modes:

  • Expression parse/type-check rejection—deterministic and fail-fast; surface as a Laravel validation error, not a 500.
  • Mode confusion—a call site silently using legacy semantics when RFC was intended (or vice versa). Mitigate by requiring an explicit mode at every call site and asserting it in tests.
  • PCRE resource limit hit—must be caught and mapped to a distinct error so it is not confused with "no match."
  • Legacy-vs-RFC semantic divergence for the same expression, which becomes a correctness bug if mode is ever changed implicitly via a package default.
  • Dependency swap to a competitor changes semantics (RFC 9535 vs Goessner draft) and silently alters results.
  • License ambiguity surfacing at audit or acquisition diligence—unresolved, and the only risk here that can block a release entirely. Ramp-up: Moderate, slightly higher than before because there are now two dialects. Engineers can no longer assume prior jsonpath intuition transfers—RFC mode's filter, slice, and union semantics plus eager type validation differ from the Goessner subset most people know. Plan a short internal guide covering when to use each mode, the function extensions, the rejection behavior, and the PCRE-limit failure mode. The compliance suite is an excellent teaching artifact; the fail-fast validator shortens the debug loop. Remaining ramp cost is standards literacy and mode discipline, not tooling.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
andydefer/laravel-notification
adachsoft/cli-process-tester
jhaskell13/laraflow
sebastienheyd/boilerplate-media-manager
ccast/tagixo-primix
pretendtrue/laravel-builder
sawmainek/laravel-scout-tntsearch-driver
tomshaw/laravel-calendar-table
dibakar/laravel-ownership
steadrun/laravel-monitor
labyrinthe/connect-laravel
elmogy/layan
drewdan/sentinel-client
dskripchenko/laravel-llm
fatryst/nuonuo
stevenay/myanfont
gmostafa/php-graphql-client
xeviant/paystack
snowsoft/faker
meditationsteps/blogetc