Tracking issue for browser compatibility

[kasperisager]

This issue tracks the remaining blockers for bundling and running Hypercore in a browser without shims. In no particular order, originally based on #52 (comment):

• Replace uses of Buffer with b4a #52
• Declare events as dependency #61
• Update hypercore-crypto to v3.1 #62
• Replace Buffer.equals() with b4a.equals() #67
• Replace Buffer with b4a and sodium-native with sodium-universal chm-diederichs/noise-curve-ed#1
• Replace Buffer with b4a holepunchto/hypercore-crypto#8
• Switch to b4a for all buffer operations holepunchto/noise-handshake#4
• Replace Buffer with b4a holepunchto/hyperswarm-secret-stream#3
• Remove remaining uses of Buffer holepunchto/hyperswarm-secret-stream#4
• Replace Buffer with b4a random-access-storage/random-access-memory#9
• Replace Buffer.alloc() with new Uint8Array() sodium-friends/sodium-javascript#62
• Replace process.nextTick with queueTick random-access-storage/random-access-memory#8
• Replace process.nextTick with queueTick random-access-storage/random-access-storage#12
• Use globalThis instead of global sodium-friends/sodium-javascript#61
• Replace Buffer with b4a mafintosh/sodium-secretstream#1
• Replace Buffer with b4a mafintosh/is-options#2
• Replace Buffer with b4a mafintosh/codecs#11
• Bundle WAT using wasm-tools mafintosh/blake2b-wasm#17
• Bundle WAT using wasm-tools mafintosh/siphash24#6
• Bundle WAT using wasm-tools mafintosh/xsalsa20#7
• Implement crypto_secretstream_xchacha20poly in sodium-javascript
• export crypto_scalarmult_ed25519 sodium-friends/sodium-javascript#65

[kasperisager]

@mafintosh I'm at a bit of an impasse with regards to EventEmitter. It's simple enough to shim with the http://npmjs.com/events module but that module cannot be installed without forcing every other dependency that imports events to use it as well. This means that the onus will be on consumers to install that module if their bundler doesn't automagically include it. esbuild, for example, will throw an error if the module isn't installed.

One option is to adopt the EventTarget web API which is supported as of Node.js 14. It's quite verbose compared to the EventEmitter API, however. Another option is forking the http://npmjs.com/events module under a name that doesn't clash with the builtin module and maybe even just fall back to the builtin module in Node.js. Thoughts?

[mafintosh]

@kasperisager ya, i say we revisit that one later and for now people need to inject that. in practice i haven't heard any "complaints" about that so we can think it through a bit.

[kasperisager]

I can contribute the first use case: The thing I'm currently working on is a browser first, Node.js second type of thing that uses streamx. Being browser first, adding events as a direct dependency seems fine, but of course does incur an unnecessary overhead when running the thing in Node.js.

[mafintosh]

actually zero overhead right, cause node should just skip it?

[mafintosh]

if you manually npm install events before bundling, does that work atm?

[kasperisager]

actually zero overhead right, cause node should just skip it?

That's absolutely true, I missed that! To actually import the events module in Node.js, and not the builtin module, one has to append a slash to the module name:

const events = require('events/')

if you manually npm install events before bundling, does that work atm?

The following import indeed uses the builtin module in Node.js and the events module in browsers, if installed:

const events = require('events')

No cow on the ice 😉 The only gotcha is of course the DX of the whole thing; modules that use the builtin events module without declaring events as a dependency won't Just Work(tm) when bundled.

[mafintosh]

Ya def, on the latter was more practical for now rather than a solution. I don’t mind potentially just including events everywhere, but we should enumerate how many modules that involves and it could be a hard ask for third party ones - let’s see