search

random-access-storage / random-access-memory

Exposes the same interface as random-access-file but instead of writing/reading data to a file it maintains it in memory
MIT License
116 stars 25 forks source link

Issues with Buffer/Uint8Array when using this module with browserify #11

Closed ralphtheninja closed 2 years ago

ralphtheninja commented 2 years ago

Hi!

This issue might be misplaced, sorry if that's the case. But lets start here and see where we end up.

So my use case is using hyperswarm-web in peermaps-web and I run into the error buf.readUInt32BE is not a function which in turns happens inside hypercore which depends on the uint64be module, which in turn tries to make the buf.readUInt32BE() call.

So the problem is that there is a mismatch between Buffer and Uint8Array somewhere and I tracked it down to the .read() method that calls b4a.alloc() https://github.com/hypercore-skunkworks/b4a/blob/main/browser.js#L33-L37

If I just rename browser.js inside b4a to _browser.js then everything just works since browserify replaces Buffer properly. Not sure if the fix should be inside b4a or if we should just remove the b4a dependency altogether and replace with Buffer.

ralphtheninja commented 2 years ago

After some clarification on Discord, using b4a is by design and it was a choice to base everything on the typed array interface in hyperdrive but this doesn't play nicely with hypercore@9. The solution was to use random-access-memory@3 until hypercore@10 will be in the dependencies for hyperdrive.