Check whether or not Buffer and Int32Array are present and support buf[index] #23

wants to merge 1 commit into


None yet
5 participants

GraemeF commented Oct 23, 2012

As I mentioned in creationix/jsonparse#10 I've run into a problem with a combination of browserify/zombie where browserify's implementation of Buffer can't implement the [] operator which jsonparse makes use of. I guess the same will happen for other polyfills too.

This pull request intends to check that whatever is given to jsonparse supports [], falling back to Int32Array and then Array if Buffer is either not available or won't work with jsonparse. The tests now pass using buffer-browserify's Buffer where they previously failed.

As you can probably tell I'm no JS expert - particularly when it comes to client-side stuff - so am prepared for ridicule/schooling as appropriate 😁


dominictarr commented Oct 23, 2012

So, it still looks to me that this is an issue with zombie, did you post an issue on zombie?
@substack what do you think? maybe this patch should go into buffer-browserify?

GraemeF commented Oct 23, 2012

I didn't because I'm able to reproduce it with the JSONStream tests just by using buffer-browserify and, although I don't fully understand why Int32Array is there (so I'm not supremely confident that that bit is right), it's clear to me that the use of buffer[] at isn't gonna work with the "writing and reading via buffer[number] does not work" limitation described in toots/buffer-browserify#1.

I also tested with an Int32Array polyfill and had the same problem: these things are unable to implement [] due to JavaScript not allowing them to.

GraemeF commented Oct 23, 2012

And yeah it's a weird one to find the right place for a fix because so many things are involved... Ideally @creationix (and everyone else) would be able to avoid using things in Buffer that aren't (and can't be) supported outside of node, but I dunno if that's possible.

I put it here because this is where the thing is created, and you were already checking to see if Buffer is there or not.


dominictarr commented Oct 23, 2012

it's just that the way I see it, the browsers are already right, because they are just browsers.
zombie only exists to make testing browser code easier, so, if there is some way that it is not like a browser,
then that is a bug in zombie.

Maybe you can make a tiny test case (just pulling enough out of buffer-browserify to reproduce your test

assert.strictEqual(new Buffer('X'), 88)

And whatever is the minimum from buffer-browserify to get this test failing in zombie, but passing in a browser.
At least you should post an issue on zombie and link back to this one.

GraemeF commented Oct 28, 2012

I'm working on that now, while trying not to pull in the whole universe with the tiny test case. 😉

Do you see what I mean about it not working in browsers if anyone is using browserify and does a require('buffer') in one of their source files or dependencies? It's just not possible to fix it in buffer-browserify due to a language restriction.

Unfortunately when you have things that can only partially emulate other things it all gets a bit messy where those things are used, if you want them to work. 😕


maxogden commented Nov 20, 2012

just ran into this same problem. this pull req should use int8 arrays and should be on this repo


maxogden commented Nov 20, 2012

actually haha i already fixed this 7 months ago #9

but for some reason it isnt working anymore.... i'm looking into it


maxogden commented Nov 20, 2012

ok the reason it doesnt work is the pull req i made predates buffer-browserify and now doesnt work because the Buffer from buffer-browserify doesnt use typed arrays like I did in #9. so a pull req to buffer-browserify that does essentially what #9 does would fix things OR another workaround is to use the typed array XHR response type which would bypass all the buffer crap and work with jsonparse today

GraemeF commented Nov 20, 2012

Ah cool, thanks @maxogden. I'll admit I was getting a bit out of my depth 😟

Would a fix in buffer-browserify work? The JSONStream code would still be using the [] operator which (as I understand it) can't be implemented on anything that isn't really an array or Buffer, which would include the Buffer from buffer-browserify.


dominictarr commented Nov 20, 2012

fixing buffer-browserify to use typed arrays seems like the best way forward.


dominictarr commented Mar 16, 2013

is this still a problem?


substack commented Mar 17, 2013

This is still a problem, yes. It was made worse in browserify 2.6.0, which detects for global Buffer references and includes a Buffer definition as necessary so detecting for the presence of Buffer will not work anymore. I started on a patch for buffer-browserify to make indexed access work by extending the array prototype but haven't gotten it working yet. The place to fix this issue in the cleanest way will be in buffer-browserify.

GraemeF commented Mar 17, 2013

That would be great! If buffer-browserify can be made to support [] then we can all relax and forget this ever happened... 😌

@GraemeF GraemeF referenced this pull request in toots/buffer-browserify Mar 18, 2013


node.js simple tests #1

toots commented Mar 18, 2013

Hi guys! I'd be very happy to fix this in buffer-browserify and would welcome any patch for that. However, typed array don't seem to be supported in enough browser to be a suitable solution..

@GraemeF GraemeF referenced this pull request in pgte/duplex-emitter Apr 1, 2013


breaks in 0.10.0 #4


substack commented Jun 27, 2014

You can close this issue since Buffer in browserify supports indexing correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment