worker_threads used on fastlify

Hi 😃

I recently started using this library in one of mine, basically as part of the build I statically compress a WASM file (level: 9) and then on load inflate it. This has been tested quite wide under browsers and Node.js (.cjs and .mjs) and it is doing quite well with only a slight overhead, but quite nice overall savings in the bundles (even when served with compression)

However, just ran into an issue logged by one of my users and don’t quite know a way forward to improve matters and solve this issue as it stands.

https://github.com/polkadot-js/api/issues/2963

So this (and it may also exist in mixed Node/browser frameworks as next.js - untested) basically means that the bundle serves from a node environment (which ignores the browser field in package.json), but executes in another environment, which actually does need that override and/or it doesn’t exist. (Not quite sure which option comes into play here, really not quite familiar with fastlify)

I actually only ever use unzlibSync (See https://github.com/polkadot-js/wasm/blob/master/packages/wasm-crypto-wasm/src/data.ts#L8), so in a perfect world would have avoided anything worker-related completely. However, in this case do get tripped up.

Any suggestions to work around this and or solve this? Preferable on this level?

Would really like to solve the linked issue, but don’t quite see any options - I guess if the parts were split into their own files (or even just sync/async), could have possibly done a direct import, avoiding workers completely. (Well, then we have tree-shaking issues since atm an export map is not required).

[jacogr]

Thanks for the quick turn-around here - I’ve asked the reporter to update. (I will also try and replicate the issue today, so will provide feedback either way, either from the reporter or myself)

[101arrowz]

I’ve updated the package as of adf1a5b and v0.4.3 on NPM, try updating. I reread the stack trace in what you linked and it’s actually a server-side issue, not client side.