Figure out which "operatingSystem" Wasm is.

[lrhn]

The current Platform.operatingSystem implementation in the new version of this package
uses Platform.operatingSystem for native and "browser" for Web.

That doesn't exhaust our platforms any more (and arguably didn't before).

When compiled to non-web JS and run on Node, it's incorrect to say that the operating system is "browser", even if dart:js is available (which is what it's currently triggering on).
But dart:io isn't available, so we also cannot use Platform.operatingSystem.

With Wasm compilation, that gets more complicated, since we can have Wasm running on different operating systems and in a browser, and we can't really tell.
And running in a non-browser Wasm runtime, doesn't mean that dart:io is available.

We should probably use Platform.operatingSystem from dart:io if it is available.
If not, we should ... try to figure out whether it's a browser (use dart:html as signifier, or can that be wrong too, if someone embeds a Dart VM into a platform with HTML display, but which isn't a full browser?

And for Wasm compiled code, we should see if there is some hint to the operating system.

[parlough]

This makes it seem to me that "browser" shouldn't be conflated with "operating system".

Personally, when I compile to JS or Wasm, I feel I am making an explicit/conscious decision for behavior to be consistent to my code no matter what the underlying native operating system is. For example, Uri always defaulting to whatever is highlighted as the "browser" behavior. When I compile to a native platform, I however expect some things to be different.

Sometimes though, there might also be changes that I want to explicitly make based on the user's underlying operating system, to match their expectations or to explicitly interact with native APIs.

So perhaps two concepts should be exposed:

• (bool) Is my app compiled for and running in a consistent, cross-platform, managed runtime (Browser, Node, Deno, Bun, Wasmtime, Wasmer, GraalVM, cross-platform Dart interpreter, etc)?
  • This doesn't exclude the operating system potentially being available as well.
• (String?) If available, what is the user/host's operating system?
  • This is nullable, as it's maybe not accessible (such as in a browser).
  • "browser" wouldn't be an option here.

[lrhn]

Making "browser" not be an OS, but making operatingSystem nullable seems doable.
I'd probably not make it nullable, but reserve the string "unknown" for that case.
It still means that the browser won't be individually detectable, separate from a plain "unknown" opting system.
Which is probably fine, but may be a breaking change for the platform package.

The boolean feels less useful.
Maybe that should be an open enum too, specifying the managed runtime the code is running in: "none" (native), "browser" (web-compiled), "nodejs", "wasm-in-browser", etc.

That's harder because it requires the runtime to identify itself, it's not decidable at compile time.

But if it's just a boolean, it's really just "not native".