Browser blockers

[Ryan Lester]

There's a Browser.T referenced in the emscripten runtime output of the current published build that doesn't refer to anything as far as I can tell, causing the output of either browserify or webpack to produce the error Uncaught ReferenceError: Browser is not defined.

Rebuilding the library fixes this, but adds an error that encode.js.mem can't be found. Adding Module['readAsync']=function(_,f){f(Module['readBinary']())}; seems to fix this, but then I get Uncaught Error: [ReadHuffmanCode] invalid num_codes or space.

You'd lose the benefits of compressing the memfile, but it may be worth considering switching to emscripten's upcoming SINGLE_FILE flag that does base64 encoding if there's no other workaround. (Is there actually a space advantage to compressing it at this stage vs leaving it to be brotli'd/gzip'd at the same time as the rest of the JS in the user's build pipeline? I'd expect the latter to at least be slightly more CPU-efficient since it'd be decompressed by native code.)

Misc issues:

• The bro command in the makefile no longer works with the latest brotli; the equivalent command is now brotli -c. (Alternatively, there's always ./vendor/brotli/bin/bro.)

• NO_BROWSER has been removed from emscripten.

[fabianmenges]

Having the same issue...

[Philippe Hebert]

Second this issue, present in Electron app

[Sergey Zenchenko]

Same for me

[Fedir Petryk]

+

[mgetz]

Getting the same error

[Bilal Quadri]

This issue also surfaces when transitively loading brotli from a jest test of a purely backend node library.

[Viktor]

I also get this error message Uncaught Error: [ReadHuffmanCode] invalid num_codes or space and have no idea what it means ...

[fabianmenges]

Looks like this project is dead... I switched to LZ4

[Ryan Lester]

I've been using LZ4 (npm package lz4) as well.

[HT]

Yapacağınız işi sikeyim kusura bakmayın

[Tim Perry]

One note that might be useful to others: this only affects the compress build, not the decompress build. require('brotli') or require('brotli/compress') fail for me, but require('brotli/decompress') works fine, and that's all I need for my case anyway.

[Devon Govett]

At this point, we could probably consider WASM as the compile target instead. I guess we could keep a fallback for IE 11 as well but all the modern browsers have WASM now. https://caniuse.com/#feat=wasm

[Devon Govett]

Now uses wasm #51