facebook/flow · error · Error

flow.js wasm export ${name} is unavailable

Error message

flow.js wasm export ${name} is unavailable

What it means

The glue resolves the wasm module's callable entry points by looking for both `_<name>` and bare `name` properties (findWasmExport) and getWasmExport throws when neither exists. It fires during module installation when the loaded Emscripten module lacks an expected export such as the flowDotJsAlloc/flowDotJsCall dispatch functions or the 'main' fallback used by installWasmModule. The usual cause is a mismatch between the generated JS glue and the .wasm sidecar binary — different build versions, a truncated/corrupt binary, or a stale artifact left next to a newer one.

Source

Thrown at src/flow_dot_js_wasm.js:102

    }
  }
  if (typeof wasmExports === 'object' && wasmExports != null) {
    if (typeof wasmExports[underscoredName] === 'function') {
      return wasmExports[underscoredName];
    }
    if (typeof wasmExports[name] === 'function') {
      return wasmExports[name];
    }
  }
  return null;
}

function getWasmExport(wasmModule, name) {
  const wasmExport = findWasmExport(wasmModule, name);
  if (wasmExport != null) {
    return wasmExport;
  }
  throw new Error(`flow.js wasm export ${name} is unavailable`);
}

function updateFlowDotJsMemoryViews() {
  if (typeof updateMemoryViews === 'function') {
    updateMemoryViews();
  }
}

function prepareFlowDotJsFallbackStack() {
  // The non-modular Buck/Emscripten output leaves the default 64KB stack.
  if (
    typeof wasmMemory !== 'object' ||
    wasmMemory == null ||
    typeof stackRestore !== 'function'
  ) {
    return;
  }
  updateFlowDotJsMemoryViews();

View on GitHub (pinned to d1341dac89)

Solutions

  1. Clean and rebuild (or reinstall) so the generated glue JS and the .wasm sidecar come from the exact same build.
  2. Verify the .wasm file is intact: correct size, starts with the wasm magic bytes (\0asm).
  3. Delete stale artifacts (old .wasm next to new .js, or vice versa) in build output and node_modules before rebuilding.
  4. If you control the build, confirm the export names (flowDotJsAlloc/flowDotJsFree/flowDotJsStringFree/flowDotJsCall or the 'main' dispatch fallback) are still emitted.

Example fix

# before: mixed artifacts from two builds
ls out/  # flow_dot_js.js (v0.2), flow_dot_js.wasm (v0.1, stale)

# after: rebuild both artifacts together
rm -rf out/ && ./build.sh  # regenerates matching .js and .wasm
Defensive patterns

Strategy: try-catch

Validate before calling

const fs = require('fs');

function wasmSidecarLooksIntact(rawJsPath, wasmPath) {
  if (!fs.existsSync(wasmPath)) return false;
  const head = fs.readFileSync(wasmPath).subarray(0, 4);
  return head[0] === 0x00 && head[1] === 0x61 && head[2] === 0x73 && head[3] === 0x6d; // \0asm
}

Try / catch

// after loadWasm/ready resolves, or around first wasm call
try {
  await flow.ready;
} catch (err) {
  if (err instanceof Error && /wasm export .* is unavailable/.test(err.message)) {
    // glue JS and .wasm sidecar are from different builds; clean and rebuild
    console.error('Stale wasm artifacts: rebuild so raw-js and .wasm match.');
    process.exitCode = 1;
  } else {
    throw err;
  }
}

Prevention

When it happens

Trigger: Mixing a flow.js wasm glue JS from one release with a .wasm sidecar from another (partial upgrade, stale node_modules or build dir); a truncated .wasm file (interrupted download/build) that instantiates partially; symbol renaming between Buck/Emscripten builds so the expected export names no longer exist.

Common situations: Incremental build caches that regenerate raw-js but reuse an old .wasm; deployments where only some artifacts were updated; downstream packagers (see flow_dot_js_wasm_packager.js) that pair mismatched raw-js and wasm inputs; local hacks renaming exported symbols.

Related errors


AI-assisted analysis of facebook/flow@d1341dac89 (2026-08-17). Data as JSON: /api/errors/0cd20c43ca83a341. Report an issue: GitHub.