We're pointing people here from tweetsodium!

[lgarron]

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 to libsodium.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:

• The .ready pattern makes it tricky to come up with code samples that work reliably in all bundlers. I wish that libsodium.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 and node).
• We had to manually exclude the package name "path" from bundlers. It is appropriately guarded so that it is only imported in node at runtime, but a lot of bundlers try to resolve it anyhow.
• Sites using CSP need to set unsafe-eval (or wasm-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.

[cognivore]

What a good news / bad news combo. Watching eagerly and I hope for some implementation plans I can contribute to.

[wisefool769]

@lgarron Is there a standard way to "disable" wasm so that I don't have to use unsafe-eval?

[lgarron]

@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.