v0.9.19

• Fixed issue that caused NaN to be returned for arrays names values

v0.9.17

• Existence tests in filter expressions now work properly, even for falsey values
• Negation of existence tests in filter expressions now work properly

v0.9.13

Fixed an issue that threw an error if an array was referenced by the string "0".

v0.9.12b - mising lines restored in minified versions

The minified and no_comments versions had non-comment (code) lines eroneously removed, they have been restored.

v0.9.12 - further refinements

Continuing the war on octal indices:

• Octal indices are not allowed.

• Numeric JSONPath expressions (e.g. $[1]) will no longer reference object properties

• Strings in JSONPath expressions (e.g. $["1"]) can still reference both array and object properties, however strings with leading zeros (e.g. $["01"]) are not allowed to reference array members, object properties however are allowed. This simple rule allows for JSON Pointer to be parsed and objectified externally without needing to know about the content of the target object. JSON Pointer syntax does not distinguish between numbers or strings they way JSONPath does.

• Octals are still allowed within script and filter expressions. The goal is only to disallow their use in array indices and not diminish the expressive power of script and filter expressions.

v0.9.11 - explicitely disallow octal indices

Octals are explicitly disallowed in array indices in this release, rather than relying on being in strict mode to do so. All other behavior is the same as v0.9.10, which includes their allowance in script and filter expressions (unless in strict mode). This is because the regex parsing does not check numbers for this (nor do I want to add the code to do so). So if you want to ensure octal indices are not allowed, yet want to allow them in your script and filter expressions: this is your release.

v0.9.10 - A major reworking of the classic JSONPath

An extensive reworking of the original Javascript JSONPath engine by Stefan Gössner ("Goessner"), but keeping with ES5 syntax and functions for broad compatibility. Here are some highlights:

• It has a completely new "normalize" engine for better syntax enforcement: Unquoted key names are no longer allowed most notably but more importantly it now has better handling of complex expressions.
• Property names containing ], ;, or that are syntactically identical to expressions like a single * or a filter expression (key) are all fully accessible with no confusion in the normalize engine.
• Key names containing Unicode characters may also be accessed using \u Unicode escape sequence. Property names containing \u0000-\u001f and \u007f, while very odd, will be properly \u escaped if PATH or PATH_DOTTED output if used for the value of the resultType property, additionally \u encoding for all Unicode characters in a property name can be enabled by setting the escapeUnicode property
• Unions can now handle key names with mixed quoting styles (single and double), multiple filter and script expressions, as well as multiple slice expressions.
• Slices now allow for negative step (reverse an array), negative array indices (truncation), as well as script expressions for creative array sampling (e.g. division)
• Strings can now be accessed by singular or multiple array indices for discreet character output as an array. They can also be sliced and maintain their stringiness.
• resulType:"PATH" still outputs bracket style paths but now defaults to double quotes with single quotes being an option via the singleQuoteKeys property. Additional resultType options have been added: PATH_DOTTED for dot style paths (when possible) and PATH_JSONPOINTER for RFC 6901 JSON Pointer output
• Script and filter expressions now check for disallowed function invocations and will terminate execution if functions other than test() match() and exec() are found. This maintains compatibility with regex queries of the original however these methods should not need to be called now since we have the =~ Ruby style regex operator that invokes test() behind the scenes; still, it's nice to have.
• == and != operators in script and filter expressions will evaluate as === and !== respectively, enforcing strict equality to ensure unexpected Javascript type coercion does not occur.
• The addition of the [-] expression, borrowed from JSON Pointer to represent the next array index after the last. While this of no use to search and retrieval (it is always non-existent), it is beneficial for JSON creation tools to be able to add to the end of an array.

Ruby style regex =~ added

jpaquit adds a clever replace() function to match =~ in something like @name =~ /key.*/, allowing for Ruby style regex syntax that fits neatly with the existing ===, ==!, ==, =! operators , see: https://github.com/jpaquit/jsonpath/tree/0.8.5-%2B-regexp

The base release from Stefan Goessner

A small, simple and elegant implementation of the JSONPath syntax ideas written in Javascript by Stefan Goessner.
This is the last version to be found at the Google Code Archive: https://code.google.com/archive/p/jsonpath/