The example in javascript/example/webgl_loader_draco.html appears to be broken on main, linking to the latest version of three.js from a CDN. Locally, the code is not compatible with three.js versions more recent than r127. r128 introduced ES6 class syntax, which requires updating the DRACOLoader implementation.

I've tested the example with this change. It works against Draco v1.5.7 but not v1.5.8. I'm hoping this could be helpful to reproduce what I believe to be a regression in the v1.5.8 WASM module. In v1.5.8 I see the following errors in the console:

wasm streaming compile failed: TypeError: Failed to execute 'fetch' on 'WorkerGlobalScope': Failed to parse URL from draco_decoder.wasm
falling back to ArrayBuffer instantiation
failed to asynchronously prepare wasm: SyntaxError: Failed to execute 'open' on 'XMLHttpRequest': Invalid URL
Aborted(SyntaxError: Failed to execute 'open' on 'XMLHttpRequest': Invalid URL)
Uncaught (in promise) RuntimeError: Aborted(SyntaxError: Failed to execute 'open' on 'XMLHttpRequest': Invalid URL). Build with -sASSERTIONS for more info.
    at U (936a93f3-0e42-4718-a…-87b8ded61578:71:35)
    at $jscomp.generator.Engine_.program_ (936a93f3-0e42-4718-a…a-87b8ded61578:70:4)
    at $jscomp.generator.Engine_.nextStep_ (936a93f3-0e42-4718-a…87b8ded61578:30:105)
    at $jscomp.generator.Engine_.throw_ (936a93f3-0e42-4718-a…87b8ded61578:28:240)
    at $jscomp.generator.Generator_.throw (936a93f3-0e42-4718-a…87b8ded61578:31:115)
    at l (936a93f3-0e42-4718-a…87b8ded61578:32:109)

In Node.js, via glTF Transform, I see a different set of errors, described in #1251, though these might be related. As three.js will eventually try to access HEAPF32, I believe it will eventually hit the same error once the immediate wasm module loading error above is resolved.

Aside - It might be worth using the version of DRACOLoader distributed with three.js rather than a local copy. That'd be easier to keep updated, though perhaps less helpful for illustrative purposes?