Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Releases: jg-rp/json-p3

Version 2.2.2

18 Mar 12:52

Choose a tag to compare

Fixes

  • Fixed an issue where we'd get syntax errors claiming "unbalanced parentheses" when the query has balanced brackets. See #43.

Version 2.2.1

23 Feb 19:58
e82a9b0

Choose a tag to compare

Fixes

  • Update iregexp-check to fix regex range quantifiers with multiple digits. See issue 40.

Version 2.2.0

18 Feb 08:47

Choose a tag to compare

Fixes

  • Fixed a bug where the non-standard current key identifier (#) would be accepted when extra JSONPath syntax is disabled.

Features

  • Added the has function extension (docs).

Version 2.1.1

30 Jan 13:32

Choose a tag to compare

Fixes

  • Fixed parsing of filter queries containing multiple consecutive bracketed segments. Previously we were failing to parse queries like $[?@[0][1]].

Version 2.1.0

23 Jan 19:35

Choose a tag to compare

Changes

  • Fixed JSONPathQuery serialization. JSONPathQuery.toString() was not handling name selectors containing ' or \, and was a bit vague about the format serialized paths would use. JSONPathQuery.toString() now accepts an options object with a single form option. form can be one of "pretty" (the default) or "canonical". The canonical format uses bracket notation and single quotes, whereas the pretty format uses shorthand notation where possible and double quotes. See issue #30 and PR #32.
  • Added JSONPathNode.getPath(options?), which returns a string representation of the node's location. As above, the form option can be one of "pretty" (the default) or "canonical".
  • Deprecated JSONPathNode.path in favour of JSONPathNode.getPath(options?).
  • Changed the string representation of filter selectors. Both canonical and pretty formats now only include parentheses where necessary.

Version 2.0.0

26 Dec 12:48

Choose a tag to compare

Breaking changes

These API changes should only affect you if you're customizing the JSONPath parser, defining custom JSONPath selectors or inspecting JSONPath.selectors (now JSONPathQuery.segments). Otherwise query parsing and evaluation remains unchanged. See issue 11 for more information.

  • Renamed JSONPath to JSONPathQuery to match terminology from RFC 9535.
  • Refactored JSONPathQuery to be composed of JSONPathSegments, each of which is composed of one or more instances of JSONPathSelector.
  • Changed abstract method JSONPathSelector.resolve and JSONPathSelector.lazyResolve to accept a single node argument instead of an array or iterator of nodes. Both still return zero or more nodes.

Version 1.3.5

04 Dec 16:44

Choose a tag to compare

Fixes

  • Fixed a JSON Patch bug where we would not allow moving or copying to the end of an array using the special JSON Pointer token -.

Version 1.3.4

05 Aug 07:08

Choose a tag to compare

Fixes

  • Fixed decoding of JSONPath escape sequences (those found in name selectors and string literals). Previously we were relying on JSON.parse() to unescape strings, now we have our own unescapeString() function that rejects invalid code points and surrogate pairs. See jsonpath-compliance-test-suite #87.
  • Fixed default minimum integer boundary for JSONPath indexes and slice steps. We were off by one.
  • Fixed parsing of JSONPath integer literals with an exponent and an upper case 'e'. We now allow 'e' to be upper case.
  • Fixed handling of trailing commas in JSONPath bracketed segments. We now raise a syntax error.
  • Fixed handling of invalid JSONPath integer and float literals with extra minus signs, leading zeros or too many zeros. We now raise a syntax error in such cases.

Version 1.3.3

21 May 06:46

Choose a tag to compare

Fixes

  • Fixed handling of JSONPath filter expression literals. We now throw a JSONPathSyntaxError if a filter expression contains a literal (string, int, float, boolean, null) that is not part of a comparison or function expression. See jsonpath-compliance-test-suite #81.

Version 1.3.2

16 May 06:08

Choose a tag to compare

Fixes

  • Fixed more I-Regexp to RegExp pattern mapping. See jsonpath-compliance-test-suite#77.
  • We now check that regular expression patterns passed to match and search are valid according to RFC 9485. The standard behavior is to silently return false from these filter function if the pattern is invalid. The throwErrors option can be passed to Match and/or Search to throw an error instead, and the iRegexpCheck option can be set to false to disable I-Regexp checks.