The wasm esm integration spec is currently stage 2. Before we add this feature (which we should) the implementors should familiarize themselves with this in-progress specification:
https://github.com/WebAssembly/esm-integration/tree/master/proposals/esm-integration
and particularly the examples:
https://github.com/WebAssembly/esm-integration/blob/master/proposals/esm-integration/EXAMPLES.md

Wasn't the only thing blocking the release of this support for "top-level await," which Deno seems to have already, putting it ahead of all of the major browsers? Doesn't the current support for top-level await make Deno non-web compatible?

@00ff0000red Top level await is implemented by V8, not Deno. And that landed in browsers just recently, so there's not even reason to argue about it

The module implementation however IS specific to the runtime, so an implementation of WASM imports that gets rushed might break the Deno phylosophy

Top level await is implemented by V8, not Deno.

It is in Deno and has been for a long time. 😕

There is nothing really holding this back other than the fact that getting the semantics to line up to something that seems stalled in the stands process is a challenge/risk.

@kitsonk I ment to say that
TLA -> Engine
WASM imports -> Runtime

Biggest problem with the non-standard feature for imports is that what if this becomes standard which is incompatible how it was implemented in Deno?

Then there is possibility it will break the code depending on the feature, and there is no good way to highlight the error lines. To mitigate that risk there could be alternate syntax, e.g.:

unstable import * as M from "./mymodule.wasm"

or even

// @deno-import
import * as M from "./mymodule.wasm"

(In example below the Deno would not allow the import at all if the @deno-import is not there)

If the wasm module imports become a standard, then it would be as simple as removing the unstable modifier (or additionally change it because it can't be known if it works with the standard that doesn't exist).

I hope I'm making sense.

now fetch wasm need network , how to cache all wasm and compile into exe ?

I think import wasm is important , when not support , so people have to hard code fetch wasm in library development , without cache

In many country for example china , network fetch from foreign site is sometimes blocked , so network fetch wasm often failed

@gcxfd Can you use Deno.readFile to load the Wasm in your specific situation?

now fetch wasm need network , how to cache all wasm and compile into exe ?

I think import wasm is important , when not support , so people have to hard code fetch wasm in library development , without cache

In many country for example china , network fetch from foreign site is sometimes blocked , so network fetch wasm often failed

You can embed the WebAssembly module as a base64 encoded string for now (this is larger and slower so not optimal but works okay enough); with import assertions for wasm we should be able to bundle it all together but that'll be a little while.

@gcxfd Can you use Deno.readFile to load the Wasm in your specific situation?

I can use readFile with my self wasm , but when I use the Third-party libraries which has wasm , I have to modify their code , This will make maintenance very troublesome .

So I think the earlier support for import wasm will earlier enable Third-party libraries with wasm in real world development

Does Deno support Request caching? Ex: fetch("./lib.wasm", { cache: "force-cache" });, if so it might make your job a bit easier.

But early support means that a lot of code might break, in various ways, once the proposal is complete, and Deno implements the standard.

Regarding the issue at hand, what's preventing an experimental re-implementation of the proposal?

I'd love to be able to start up my code by running deno run -A --unstable ./main.wasm; :), even if it's experimental.

Closing as duplicate of #2552