Improve Webpack loader

[xtuc]

With the new wasm pipeline in Webpack (> 4.8.0), loader can now directly emit a wasm binary.

I have a very simple demo here: https://github.com/xtuc/c-webpack-demo.

The idea would be to allow:

  module: {
    rules: [
      {
        test: /\.ts$/,
        loader: "@assemblyscript/loader",
        type: "webassembly/experimental"
      }
    ]
  },

and the user would just:

import("./foo.ts").then(...)

[dcodeIO]

Thanks for the insights! Does the import in this case return a WebAssembly.Module one can instantiate? Ultimately I'd like @assemblyscript/loader to provide the utility mentioned in the README and also integrate with webpack. The challenge here seems to be to return something that can a) be instantiated by providing the necessary imports and b) matches the .d.ts generated by the compiler by running the demangler on the WASM exports first.

[dcodeIO]

Btw. here's a prototype for the webpack component, but I'm not quite content with the base64 encoding step because it breaks source map support.

[xtuc]

Does the import in this case return a WebAssembly.Module one can instantiate

No it will return the WebAssembly.Module.exports basically.

Ultimately I'd like @assemblyscript/loader to provide the utility mentioned in the README

We'll use instantiateStreaming when available and fallback if not.

For demangle you have the object with the exports, is that ok?

be instantiated by providing the necessary imports

Webpack will do the linking, you need to emit and require local files.

prototype for the webpack

Yes I saw it, synchronous + inline buffer approach has many disadvantages. I wouldn't recommend it.

[dcodeIO]

I see, thanks. So proper integration with webpack will require support for external imports in AssemblyScript first because there is no other way to specify imports :)

[xtuc]

Yeah, maybe we can keep it internal just to test the integration but that would also enable a better integration with the user's JavaScript code.

[dcodeIO]

Yeah, one of the reasons why it's currently using the declare syntax and picking imports from ambient contexts is that this way both import styles can be supported eventually, with imports mapping to what will become es module integration (as now in webpack, I suppose), and declare remaining as a more direct mechanism to specifiy import namespaces manually (i.e. for non-web embeddings). So webpack might be a good initial testing ground for es module integration.

[trusktr]

Does the import in this case return a WebAssembly.Module one can instantiate?

I think it'd be great (if this isn't the case already) that an AssemblyScript module could export a class or function, and that the JS side could use it like a class or function with the same types as defined on the AssemblyScript side (internally the module would wrap the WASM Module and make the wrapper methods call into the WASM module, etc).

Eventually the internal implementation could be replaced with references and object types to make it fast.

[trusktr]

Using the example from assemblyscript-typescript-loader, if we have some AssemblyScript code:

// ... code omitted for brevity ...
export function step(): void {
  // ... code omitted for brevity ...
}

then instead of importing it into regular TypeScript like this:

import asmPromise from "./assemblyscript/moduleEntry.ts";
asmPromise().then(function(asmModule){
  // here you can use the wasm.exports
  asmModule.step();
})

we'd import it like the following (which will work with top-level await):

import {step} from "./assemblyscript/moduleEntry.ts";

// use the wasm.exports
step()

[dcodeIO]

Closing this issue as part of 2020 vacuum because it has been lingering for quite some time without being resolved. If it's still an issue important to you, feel free to open a new one!

[jerrygreen]

Wait, does that mean I can setup my webpack config like that? Or there should be some glue-code from @assemblyscript/loader, too?