I'm trying to use jsonparse (via @dominictarr's JSONStream) with browserify and, since buffer-browserify doesn't (and apparently can't) support buf[index] it doesn't work.
JSONStream already detects whether Buffer is available so maybe that could detect browserify buffers and choose not to use them, but maybe it would be better if jsonparse could deal with it itself?
What do y'all think?
hmm, this is strange, I know @substack uses JSONStream a lot, in browserify.
@graemef can you post a script to reproduce?
Good to hear, probably just me then. But it is definitely strange so here's the whole story... It works fine in Chrome and Firefox but I'm running end-to-end tests using zombie and it's there that I see the problem.
I found that using a browserify Buffer makes the existing tests fail in the same way (or maybe in a different way that happens to look the same 😊 ), so that's an easy way to repro: GraemeF/JSONStream@d4e1cb5
right, so this is a bug in zombie then.
I don't think so; with the original code in the browser I'm seeing that Buffer is undefined so it hits the other code path at https://github.com/dominictarr/JSONStream/blob/master/index.js#L75 and works.
If you have code that does a require('buffer').Buffer in the browser then browserify will substitute it and then the failing path will be taken. I think zombie just happens to have the right conditions to make it hit the other path and fail.
Anyway, by explaining it I think I now understand the problem sufficiently enough to make a pull request (for JSONStream not jsonparse; sorry to hijack your issues list @creationix - I wasn't clear where the fix would be most appropriate until now!).
Why not just set the encoding to always use strings? In node you can choose between Buffer instances and strings. I'm sure browserify has this same option. (If it doesn't it should and it's easy to implement)
@creationix - that sounds plausible, I'll take a look. Thanks!