Closed CryZe closed 1 year ago
Hey there, thanks for the PR. To make sure I understand correctly, there are two intents with this?
sys-locale
so the only way to properly support that target is through a wasm-web feature
Do you have strong opinions on the variable name? Other crates, such as getrandom
and ring
, seem to have settled on having js
somewhere in the name to indicate access to wasm-bindgen
-like code.
Regarding the others, do you know if WASI or Emscripten support getting the locale information from the runtime? I found this PR for Emscripten that seems to provide it via ENV['LANG']
but WASI does not appear to support this yet.
Do you have strong opinions on the variable name? Other crates, such as getrandom and ring, seem to have settled on having js somewhere in the name to indicate access to wasm-bindgen-like code.
I don't particularly care about the feature name, so js
is fine with me (although web seems more accurate than JS as you are interacting with the Web APIs and not necessarily with JS, especially in the future where WASM doesn't need any glue code anymore).
Regarding the others, do you know if WASI or Emscripten support getting the locale information from the runtime? I found https://github.com/emscripten-core/emscripten/pull/8751 for Emscripten that seems to provide it via ENV['LANG'] but WASI https://github.com/WebAssembly/WASI/issues/167 appear to support this yet.
Yeah so it doesn't look like WASI can be supported yet, but as it turns out, Emscripten counts as a Unix, so the approach in the Unix code should work. However that means that Emscripten satisifes both WASM and Unix, so I'll push a fix that ensures Emscripten doesn't accidentally compile in two implementations.
This should be ready again.
This is now released as v0.3.0
on crates.io.
Thank you so much :)
The crate previously assumed that
wasm-bindgen
can be used for every WebAssembly target. However there's essentially the following 4 targets:Only
WebAssembly on the web
supportswasm-bindgen
. Unfortunately that's not a target on its own for historical reasons, so the only way to properly support that target is through awasm-web
feature. All other WebAssembly targets now fall back onto a new fallback implementation that always returnsNone
. The crate now also should be able to build at all on unsupported targets because of that.This is technically a breaking change that requires a new "major version" (0.3.0).