Currently both wasm-bindgen and wasm-pack are built to target a specific platform: either the web, in which case the .wasm file is loaded with fetch(), or nodejs - and then the .wasm file is loaded from the filesystem with fs.
The goal here is to inject the resulting code (JS and wasm) into the TypeScript source files and use its build system (gulp) to create a WebAssembly-powered version of TypeScript.
The problem is that even though TypeScript is meant to run in nodejs, the build configuration is self-contained without dependencies on external files. It would be too complicated to import (and acknowledge the types of) the fs module and make sure that the .wasm file is copied along with the source files in the gulp pipeline.
A possible solution, which I will try to build a prototype of, is to inline the .wasm file in the JS output, serialized as a base64 string. Deserializing the base64 string and creating a UInt8Array out of it could be done platform-independently.
Currently both wasm-bindgen and wasm-pack are built to target a specific platform: either the web, in which case the
.wasmfile is loaded withfetch(), or nodejs - and then the.wasmfile is loaded from the filesystem withfs.The goal here is to inject the resulting code (JS and wasm) into the TypeScript source files and use its build system (
gulp) to create a WebAssembly-powered version of TypeScript.The problem is that even though TypeScript is meant to run in nodejs, the build configuration is self-contained without dependencies on external files. It would be too complicated to import (and acknowledge the types of) the
fsmodule and make sure that the.wasmfile is copied along with the source files in thegulppipeline.A possible solution, which I will try to build a prototype of, is to inline the
.wasmfile in the JS output, serialized as a base64 string. Deserializing the base64 string and creating aUInt8Arrayout of it could be done platform-independently.