Mo Morsi

Continuing on... it seems sys/unix/Makefile.utl attempts to prepend the ../win/web/mount_nodefs.js source to the 'compiled' js output. This file contains the 'require' lines throwing the interpreter off. Additionally the unix/Makefile.utl attempts...

I dug into this a bit a little later and realized the 'js' command in the makefiles should actually be 'node' for the nodejs interpreter. After changes all the references...

We just pushed *yet another fork* this one utilizing **v8-sandbox** as an alternative / safer expression evaluation backend. It can be accessed [here](https://github.com/devnullprod/jsonpath-sandbox#readme)

@rezonant glad to hear. Yes our fork is currently nodejs only, perhaps we'll investigate if it can be exposed to a browser environment in the future. Appreciate the heads up...

If the library is stable activity isn't a big issue as changes are rarely needed. But yes it does seem like jison-gho has various important issues / PRs open that...

@SaeedZhiany ```javascript const jp = require('jsonpath') const expression = "$.foo.bar" try{ jp.parse(expression) // expression is valid! }catch(err){ // ruh-oh! you passed a bad expression... } ```

We just pushed a similar commit to our fork (available on npm): https://github.com/DevNullProd/jsonpath-sandbox/commit/f62ddee33aee04c2177bdaa4938bd865183f461c

We pushed a follow on patch allowing the user to set a timeout to expire the cache. Thus the memoized values will not grow in memory indefinitely. https://github.com/DevNullProd/jsonpath-sandbox/commit/dffaa749885e9b039e61d91230c9bc76c425bb75

jsonpath-sandbox 1.0.3 was just pushed to github and npm including performance optimizations and a a new 'complexity' function returning quantitative representation of expression complexity

@cthorner stringify takes an input representative of JSONPath components, either as an array of strings or an array of parsed path expressions, and converts them into a string path: **jp.stringify(path)**...