cannot load C++ parser, using JS implementation

[pashoo2]

This error has reached if the library was compiled with the node js v0.12 or the last version of iojs

[pashoo2]

If it compiled with the node v0.10, then there is no error

[pashoo2]

if compiled OK and then run under the node v.0.12 it's allright

[bjouhier]

This is the expected behavior. I can improve it by having an install script that deploys binaries in bin/os-arch-v8-version subdirectories.

[amark]

@bjouhier hey, thanks for this!!! I got ~20M monthly users, desperately needing to reduce JSON parse blocking time, looking into this.

I can't get it to install at all on my mac (some complaint about xcode, ugh) due to the node-gyp part failing, but this means npm doesn't finish the install for even the remaining JS version!

Any chance you'd be willing to move the node-gyp part to an optional section? (would post-install work?) so that way at least the JS version is available?

Also, I want to say I'm really impressed, and want to commend you for working on this.

Unless I did my research wrong (multiple days), there are barely any proper async (as in CPU partitioning) JSON parsers out there, despite the fact this seems like an obvious thing every website in the world would have needed for at least a decade+! This boggles my mind. Am I missing something? Would you still recommend in 2020 that i-json is the best option? The only other (proper) async (CPU partitioning) option I noticed was something from IBM (tho it was open source). The whole "streaming" JSON libraries are infinitely popular but seem to miss the important boat by being synchronous or feature bloat. Seems like i-json is literally the only option unless I hand roll (really don't want to, but hey, I had to write a CPU scheduler in JS the other day... so...), any tips or latest thoughts/updates for 2020?

[bjouhier]

@amark I haven't worked on this package for a while. It works on mac with node 10 but got broken by node 12 C++ API changes.
I won't have time to work on it this week but maybe next week-end. In the mean time you may be able the just extrace the parser.js source.
I don't know if there is an easy way to make the node-gyp part optional. The node-gyp compilation is somewhat built into npm install but maybe there is a way to control it (haven't investigated yet). If you find a way let me know and I can publish a fix.

[amark]

@bjouhier no worries, and thanks for the reply.

There was a few other changes I wanted outside the scope of ijson, so I did wind up writing my own custom parser.

I had already made some edits to ijson, such as fixing new Buffer warnings, to Buffer.from( etc., made that a PR in case it is helpful to you (no worries accepting/rejecting).

Would it be OK if I stole your tests tho? How thorough are the escape sequences / edge cases? I haven't done much research on this front. Are there an exhaustive set of edge cases that you already have researched/tested? Or more/others to be added?

Thanks again for your work! :)