Closed lgarron closed 1 year ago
What a good news / bad news combo. Watching eagerly and I hope for some implementation plans I can contribute to.
@lgarron Is there a standard way to "disable" wasm so that I don't have to use unsafe-eval
?
@lgarron Is there a standard way to "disable" wasm so that I don't have to use
unsafe-eval
?
You'd have to ask @jedisct1. But — given that the library's main purpose is to be a wasm
port — that sounds unlikely to me.
Ahoy!
https://github.com/github/tweetsodium is currently used by ≈10,000 projects on GitHub, which is almost as many as
libsodium.js
itself (≈13,000).We are no longer maintaining
tweetsodium
at GitHub, and have added code samples for projects to switch over tolibsodium.js
:https://github.com/github/tweetsodium#%EF%B8%8F-tweetsodium-is-deprecated-and-unmaintained-%EF%B8%8F
We ran into the following potential compatibility issues:
.ready
pattern makes it tricky to come up with code samples that work reliably in all bundlers. I wish thatlibsodium.js
could handle this for everyone using top-level await, but unfortunately that approach has inconsistent support in bundlers as well (even though it works perfectly in modern browsers andnode
)."path"
from bundlers. It is appropriately guarded so that it is only imported innode
at runtime, but a lot of bundlers try to resolve it anyhow.unsafe-eval
(orwasm-unsafe-eval
once that's available in all browsers) in order to run the WASM code.None of these are the fault of
libsodium.js
, but you may get an increase in questions about such issues.