emscripten-wasm-loader

Emscripten-wasm-loader

Wraps up common initialization logic with predefined preprocessor object. This module intended to support specific scoped usecase for wasm binary built with MODULARIZED and SINGLE_FILE.

Usage

import { getModuleLoader } from 'emscripten-wasm-loader';

const loader = getModuleLoader(factoryLoader, require('wasm/wasmlibaray'), { additional: ''});

getModuleLoader is higher order function returns actual module loader.

getModuleLoader<T, R extends AsmRuntimeType>(
  factoryLoader: (runtime: R) => T,
  runtimeModule: runtimeModuleType,
  module?: stringMap
) => moduleLoaderType<T>;

/**
 * Asynchronously load and initialize asm module.
 *
 * @param {ENVIRONMENT} [environment] Override running environment to load binary module.
 * This option is mostly for Electron's renderer process, which is detected as node.js env by default
 * but in case of would like to use fetch to download binary module.
 *
 * @returns {T} Factory function manages lifecycle of hunspell and virtual files.
 */
type moduleLoaderType<T> = (environment?: ENVIRONMENT) => Promise<T>;

factoryLoader is callback function to be called to create actual instance of module using initialized wasm binary runtime for customized init steps for each consumer. runtimeModule is function loaded via require to emscripten preamble js for wasm binaries. It expects wasm binary should be built with MODULARIZE=1 with SINGLE_FILE=1 option. Lastly module is object to be inherited when execute runtimeModule. Emscripten's modularized preamble construct scoped wasm runtime module named Module, allows to have predefined object if needed. Internally getModuleLoader augments given object and set default interfaces like initializeRuntime.

Changelog

1.0.0 (2017-11-29)

Features

• getmoduleloader: drop custom binarypath support (2f9fb92)

BREAKING CHANGES

• getmoduleloader: Loader now accepts single file, native wasm module only

<a name="0.0.8"></a>