Repro:

npx degit nvh95/vite-react-template-redux/typescript my-app --yarn
// bump vite to 3.0 in package.json
yarn dev

Error:

failed to load config from /Users/jiawengeng/code/monkey-rust/packages/playground/vite.config.ts
error when starting dev server:
Error [ERR_REQUIRE_ESM]: require() of ES Module /Users/jiawengeng/code/monkey-rust/node_modules/.pnpm/[email protected][email protected]/node_modules/vite-plugin-wasm/dist/index.js from /Users/jiawengeng/code/monkey-rust/packages/playground/vite.config.ts not supported.

I get the following error when I'm building my Nuxt 3 project with yarn build (nuxt build) using vite-plugin-wasm.

Unexpected character '' (Note that you need plugins to import files that are not JavaScript)                                 09:02:57

  at error (node_modules/rollup/dist/es/shared/rollup.js:1858:30)
  at Module.error (node_modules/rollup/dist/es/shared/rollup.js:12412:16)
  at Module.tryParse (node_modules/rollup/dist/es/shared/rollup.js:12789:25)
  at Module.setSource (node_modules/rollup/dist/es/shared/rollup.js:12694:24)
  at ModuleLoader.addModuleSource (node_modules/rollup/dist/es/shared/rollup.js:22136:20)

My vite.config.ts looks like this:

import wasm from 'vite-plugin-wasm'

/** @type {import('vite').UserConfig} */
export default {
	build: {
    target: 'esnext'
  },
  plugins: [
		wasm(),
	],
  server: {
    watch: {
      usePolling: true
    }
  }
}

This is the wasm lib I'm using. When I comment the import line the build runs without any problems.

import CardanoSerializationLibrary from '@emurgo/cardano-serialization-lib-browser/cardano_serialization_lib'

class Loader {
  _wasm: typeof CardanoSerializationLibrary | undefined

  async load() {
    if (this._wasm) return
    this._wasm = await import('@emurgo/cardano-serialization-lib-browser/cardano_serialization_lib')
  }

  get Cardano() {
    return this._wasm
  }
}

export default new Loader()

Unfortunately, I'm stuck with this issue. Any help is appreciated.

I'm having a problem when building a Vite 3 / Vue.js 3 project that calls a wasm from within a web worker.

Everything seems to work fine when I test the app locally, using "yarn dev". However, when I attempt to build it for production, using "yarn build", I get the following error:

yarn run v1.22.19
$ vue-tsc --noEmit && vite build
vite v3.1.2 building for production...
✓ 3 modules transformed.
✓ 17 modules transformed.
[vite:worker-import-meta-url] Could not load /Users/gdaley/wasm-test/src/hello_wasm/pkg/hello_wasm_bg.wasm (imported by src/hello_wasm/pkg/hello_wasm.js): Cannot read properties of undefined (reading 'load')
file: /Users/gdaley/wasm-test/src/components/HelloWorld.vue?vue&type=script&setup=true&lang.ts
error during build:
TypeError: Could not load /Users/gdaley/wasm-test/src/hello_wasm/pkg/hello_wasm_bg.wasm (imported by src/hello_wasm/pkg/hello_wasm.js): Cannot read properties of undefined (reading 'load')
    at Object.load (/Users/gdaley/wasm-test/node_modules/vite-plugin-wasm/dist/index.js:52:66)
    at async file:///Users/gdaley/wasm-test/node_modules/rollup/dist/es/shared/rollup.js:22113:98
    at async Queue.work (file:///Users/gdaley/wasm-test/node_modules/rollup/dist/es/shared/rollup.js:22820:32)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

I have created a simple project, to illustrate this issue.

Could you please let me know if calling wasm functions from web workers is supported currently, and if so, what I'm doing wrong?

I'm importing the package '@dimforge/rapier2d', which contains WASM files.

My Vite config file:

import { defineConfig } from 'vite'
import wasm from 'vite-plugin-wasm'
import topLevelAwait from 'vite-plugin-top-level-await'

export default defineConfig({
	plugins: [
		/**
		 * Since 2.x version of this plugin, the `filter` option has been removed.
		 *
		 * For 1.x (with Vite 2.x):
		 *   By default ALL `.wasm` imports will be transformed to WebAssembly ES module.
		 *   You can also set a filter (function or regex) to match files you want to transform.
		 *   Other files will fallback to Vite's default WASM loader (i.e. You need to call `initWasm()` for them).
		 *   ```js
		 *   wasm({
		 *     filter: /syntect_bg.wasm$/
		 *   })
		 *   ```
		 */
		wasm(),
		topLevelAwait(),
	],
    server: {
        port: 9001
    },
})

Error:

X [ERROR] No loader is configured for ".wasm" files: node_modules/@dimforge/rapier2d/rapier_wasm2d_bg.wasm

    node_modules/@dimforge/rapier2d/rapier_wasm2d.js:1:22:
      1 │ import * as wasm from "./rapier_wasm2d_bg.wasm";
        ╵                       ~~~~~~~~~~~~~~~~~~~~~~~~~

C:\Users\yisha\Gits\Shuch\node_modules\esbuild\lib\main.js:1605
  let error = new Error(`${text}${summary}`);
              ^

Error: Build failed with 1 error:
node_modules/@dimforge/rapier2d/rapier_wasm2d.js:1:22: ERROR: No loader is configured for ".wasm" files: node_modules/@dimforge/rapier2d/rapier_wasm2d_bg.wasm
    at failureErrorWithLog (C:\Users\yisha\Gits\Shuch\node_modules\esbuild\lib\main.js:1605:15)
    at C:\Users\yisha\Gits\Shuch\node_modules\esbuild\lib\main.js:1251:28
    at runOnEndCallbacks (C:\Users\yisha\Gits\Shuch\node_modules\esbuild\lib\main.js:1034:63)
    at buildResponseToResult (C:\Users\yisha\Gits\Shuch\node_modules\esbuild\lib\main.js:1249:7)
    at C:\Users\yisha\Gits\Shuch\node_modules\esbuild\lib\main.js:1358:14
    at C:\Users\yisha\Gits\Shuch\node_modules\esbuild\lib\main.js:666:9
    at handleIncomingPacket (C:\Users\yisha\Gits\Shuch\node_modules\esbuild\lib\main.js:763:9)
    at Socket.readFromStdout (C:\Users\yisha\Gits\Shuch\node_modules\esbuild\lib\main.js:632:7)
    at Socket.emit (node:events:527:28)
    at addChunk (node:internal/streams/readable:315:12) {
  errors: [
    {
      detail: undefined,
      id: '',
      location: {
        column: 22,
        file: 'node_modules/@dimforge/rapier2d/rapier_wasm2d.js',
        length: 25,
        line: 1,
        lineText: 'import * as wasm from "./rapier_wasm2d_bg.wasm";',
        namespace: '',
        suggestion: ''
      },
      notes: [],
      pluginName: '',
      text: 'No loader is configured for ".wasm" files: node_modules/@dimforge/rapier2d/rapier_wasm2d_bg.wasm'
    }
  ],
  warnings: []
}

Can't find any information about this error, anywhere.

I am trying to use a wasm with Nuxt3 but it keeps failing...anyone that can help me with configuration?

nuxt.config.ts

import wasm from 'vite-plugin-wasm';

export default defineNuxtConfig({
    vite: {
        plugins: [
            wasm()
        ]
    }
})

This pr solve #1.

Why some wasm functions return undefined?

If you import a wasm js module:

import { parse } from "@jsona/openapi";
console.log(parse("{}"));

vite will compile this to:

import { parse } from "/node_modules/@jsona/openapi/index_bg.js?v=bb17ff0c"; 

NOTE: vite append a version hash to module path.

vite-wasm-plugin will resolve this to:

import __vite__initWasm from "/__vite-plugin-wasm-helper"
import { __wbindgen_json_parse as __vite__wasmImport_0_0 } from "/node_modules/@jsona/openapi/index_bg.js";
const __vite__wasmModule = await __vite__initWasm({ "./index_bg.js": { __wbindgen_json_parse: __vite__wasmImport_0_0 } }, "/node_modules/@jsona/openapi/index_bg.wasm?init");
export const memory = __vite__wasmModule.memory;
export const parse = __vite__wasmModule.parse;
export const __wbindgen_malloc = __vite__wasmModule.__wbindgen_malloc;
export const __wbindgen_realloc = __vite__wasmModule.__wbindgen_realloc;

vite-wasm-plugin imports the importer module /node_modules/@jsona/openapi/index_bg.js without a version hash.

That's the problem. They are two different modules because their paths are different.

If you run non-local wasm js module(vite don't add version hash to non-node_module files), call a function depends on __wbindgen* function, it will return undefined.

Steps to reproduce:

1. Do the wasm-pack tutorial
2. Install Vite with this plugin
3. Get error: Cannot access memory before initialization on the bg file. (Truncated below):

import * as wasm from '/-/hello-wasm/hello_wasm_bg.wasm?import';

let cachedUint8Memory0;
function getUint8Memory0() {
    if (cachedUint8Memory0.byteLength === 0) {
        cachedUint8Memory0 = new Uint8Array(wasm.memory.buffer);
    }
    return cachedUint8Memory0;
}

cachedUint8Memory0 = new Uint8Array(wasm.memory.buffer); // Uncaught ReferenceError: Cannot access 'memory' before initialization

The memory checking seems to have been changed since this PR: https://github.com/rustwasm/wasm-bindgen/pull/2886 and I'm guessing the initialization logic is different from what's now needed since the wasm file is referenced in the top level.

Hi, I'm facing issues when using this package together with wasm-bindgen and having the return type as JsValue. I've tried loading the same wasm module using webpack without any issues, suggesting that the issue is with how the wasm module is loaded.

Changing the signature to return string fixes the issue...

https://github.com/fredrikjacobson/wasm-jsvalue-undefined contains a reproduction where

yarn dev

and checking the console log yields undefined. Running npm start from ./rust-wasm however will print the correct js object.

I would guess that some part of the glue-code from wasm-bindgen somehow gets removed.

Essentially switching from

// This does not work since the value comes back as undefined...
serde_wasm_bindgen::to_value(&features).map_err(|e| JsError::new(&e.to_string()))

to

serde_json::to_string(&features).map_err(|e| JsError::new(&e.to_string()))

fixes the problem by returning string instead.

Any idea for why I'm facing issue using this plugin vs. webpack?

Thanks

Using wasm-pack and a "file:path" dependency with yarn to my wasm package. I can use the init function from the package and I've verified that it is running the wasm binary, but when I try to import { memory } from the .wasm file I get this error:

[vite] Internal server error: Failed to resolve import "wbg" from "node_modules/.../lib_bg.wasm". Does the file exist?

The file does exist, so not quite sure what's happening here.

[vite] Internal server error: Failed to resolve import "wbg" from "node_modules/golem/lib_bg.wasm". Does the file exist?
  Plugin: vite:import-analysis
  File: /Users/ted/git/golem/node_modules/golem/lib_bg.wasm
  1  |
  2  |  import __vite__initWasm from "/__vite-plugin-wasm-helper"
  3  |  import { __wbg_new_693216e109162396 as __vite__wasmImport_0_0, __wbg_stack_0ddaca5d1abfb52f as __vite__wasmImport_0_1, __wbg_error_09919627ac0992f5 as __vite__wasmImport_0_2, __wbindgen_object_drop_ref as __vite__wasmImport_0_3, __wbg_self_ba1ddafe9ea7a3a2 as __vite__wasmImport_0_4, __wbg_window_be3cc430364fd32c as __vite__wasmImport_0_5, __wbg_globalThis_56d9c9f814daeeee as __vite__wasmImport_0_6, __wbg_global_8c35aeee4ac77f2b as __vite__wasmImport_0_7, __wbindgen_is_undefined as __vite__wasmImport_0_8, __wbg_newnoargs_fc5356289219b93b as __vite__wasmImport_0_9, __wbg_call_4573f605ca4b5f10 as __vite__wasmImport_0_10, __wbindgen_object_clone_ref as __vite__wasmImport_0_11, __wbg_process_e56fd54cf6319b6c as __vite__wasmImport_0_12, __wbindgen_is_object as __vite__wasmImport_0_13, __wbg_versions_77e21455908dad33 as __vite__wasmImport_0_14, __wbg_node_0dd25d832e4785d5 as __vite__wasmImport_0_15, __wbindgen_is_string as __vite__wasmImport_0_16, __wbg_static_accessor_NODE_MODULE_26b231378c1be7dd as __vite__wasmImport_0_17, __wbg_require_0db1598d9ccecb30 as __vite__wasmImport_0_18, __wbg_crypto_b95d7173266618a9 as __vite__wasmImport_0_19, __wbg_msCrypto_5a86d77a66230f81 as __vite__wasmImport_0_20, __wbg_newwithlength_e833b89f9db02732 as __vite__wasmImport_0_21, __wbg_randomFillSync_91e2b39becca6147 as __vite__wasmImport_0_22, __wbg_subarray_9482ae5cd5cd99d3 as __vite__wasmImport_0_23, __wbg_getRandomValues_b14734aa289bc356 as __vite__wasmImport_0_24, __wbg_length_e09c0b925ab8de5d as __vite__wasmImport_0_25, __wbindgen_memory as __vite__wasmImport_0_26, __wbg_buffer_de1150f91b23aa89 as __vite__wasmImport_0_27, __wbg_new_97cf52648830a70d as __vite__wasmImport_0_28, __wbg_set_a0172b213e2469e9 as __vite__wasmImport_0_29, __wbindgen_throw as __vite__wasmImport_0_30 } from "wbg";
     |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   ^
  4  |  const __vite__wasmModule = await __vite__initWasm({ "wbg": { __wbg_new_693216e109162396: __vite__wasmImport_0_0, __wbg_stack_0ddaca5d1abfb52f: __vite__wasmImport_0_1, __wbg_error_09919627ac0992f5: __vite__wasmImport_0_2, __wbindgen_object_drop_ref: __vite__wasmImport_0_3, __wbg_self_ba1ddafe9ea7a3a2: __vite__wasmImport_0_4, __wbg_window_be3cc430364fd32c: __vite__wasmImport_0_5, __wbg_globalThis_56d9c9f814daeeee: __vite__wasmImport_0_6, __wbg_global_8c35aeee4ac77f2b: __vite__wasmImport_0_7, __wbindgen_is_undefined: __vite__wasmImport_0_8, __wbg_newnoargs_fc5356289219b93b: __vite__wasmImport_0_9, __wbg_call_4573f605ca4b5f10: __vite__wasmImport_0_10, __wbindgen_object_clone_ref: __vite__wasmImport_0_11, __wbg_process_e56fd54cf6319b6c: __vite__wasmImport_0_12, __wbindgen_is_object: __vite__wasmImport_0_13, __wbg_versions_77e21455908dad33: __vite__wasmImport_0_14, __wbg_node_0dd25d832e4785d5: __vite__wasmImport_0_15, __wbindgen_is_string: __vite__wasmImport_0_16, __wbg_static_accessor_NODE_MODULE_26b231378c1be7dd: __vite__wasmImport_0_17, __wbg_require_0db1598d9ccecb30: __vite__wasmImport_0_18, __wbg_crypto_b95d7173266618a9: __vite__wasmImport_0_19, __wbg_msCrypto_5a86d77a66230f81: __vite__wasmImport_0_20, __wbg_newwithlength_e833b89f9db02732: __vite__wasmImport_0_21, __wbg_randomFillSync_91e2b39becca6147: __vite__wasmImport_0_22, __wbg_subarray_9482ae5cd5cd99d3: __vite__wasmImport_0_23, __wbg_getRandomValues_b14734aa289bc356: __vite__wasmImport_0_24, __wbg_length_e09c0b925ab8de5d: __vite__wasmImport_0_25, __wbindgen_memory: __vite__wasmImport_0_26, __wbg_buffer_de1150f91b23aa89: __vite__wasmImport_0_27, __wbg_new_97cf52648830a70d: __vite__wasmImport_0_28, __wbg_set_a0172b213e2469e9: __vite__wasmImport_0_29, __wbindgen_throw: __vite__wasmImport_0_30 } }, "/node_modules/golem/lib_bg.wasm?init");
  5  |  export const memory = __vite__wasmModule.memory;
      at formatError (file:///Users/ted/git/golem/node_modules/vite/dist/node/chunks/dep-1513d487.js:35028:46)
      at TransformContext.error (file:///Users/ted/git/golem/node_modules/vite/dist/node/chunks/dep-1513d487.js:35024:19)
      at normalizeUrl (file:///Users/ted/git/golem/node_modules/vite/dist/node/chunks/dep-1513d487.js:40145:33)
      at async TransformContext.transform (file:///Users/ted/git/golem/node_modules/vite/dist/node/chunks/dep-1513d487.js:40279:47)
      at async Object.transform (file:///Users/ted/git/golem/node_modules/vite/dist/node/chunks/dep-1513d487.js:35277:30)
      at async loadAndTransform (file:///Users/ted/git/golem/node_modules/vite/dist/node/chunks/dep-1513d487.js:39776:29)

Given you're using a default export in your index.ts in combination with "module": "CommonJS", in your tsconfig.json there are currently "two levels" of default exports.

My current workaround:

I use vite 3.1, and I'm trying to use this project to load wasm-pack created package. I'm doing

wasm-pack build <package> --target web
wasm-pack pack <package> 
yarn add ./<package>/pkg/<pkg>-<version>.tgz

typescript is fine with this, I'm not getting errors so the package is there. When I inspect node_modules, all the files are also there. but for some reason, in .vite/deps/ there's just the .js files (no sign of *_bg.wasm files) here's the full error:

Not found: /node_modules/.vite/deps/wasm_launcher_extensions_bg.wasm
Error: Not found: /node_modules/.vite/deps/wasm_launcher_extensions_bg.wasm
    at resolve (file:///C:/Users/niedzwiedz-serwer/blazing-client/node_modules/@sveltejs/kit/src/runtime/server/index.js:267:13)
    at Object.handle (file:///C:/Users/niedzwiedz-serwer/blazing-client/node_modules/@sveltejs/kit/src/exports/vite/dev/index.js:336:66)
    at respond (file:///C:/Users/niedzwiedz-serwer/blazing-client/node_modules/@sveltejs/kit/src/runtime/server/index.js:295:40)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async file:///C:/Users/niedzwiedz-serwer/blazing-client/node_modules/@sveltejs/kit/src/exports/vite/dev/index.js:406:22

this happens when I run yarn dev

I had a NextJS project setup where I would build a rust library with wasm-pack, install it with file:wasm-bindgen-module, set asyncWebAssembly on the Webpack config and then import and use it like this:

import { f } from "wasm-bindgen-module";
f();

I am now moving over to SvelteKit and the "(aka. Webpack's asyncWebAssembly)" led me to believe I would be able to do the same but when I do onMount(() => f()), I get Cannot read properties of undefined (reading 'f').

Here's my vite.config.js:

const config = {
	plugins: [sveltekit(), wasm(), topLevelAwait()],
	optimizeDeps: {
		exclude: ["wasm-bindgen-module"],
	},
};

Am I missing anything?

AFAIK Firefox doesn't support ESM in workers ATM so setting workers.format to es will break the resulting sure in Firefox. I think Vite explicitly has code to transform workers in dev mode rather than rely on ESM so they will work in Firefox. Any way to get this plugin to work with classic workers?

This PR is an initial stab at enabling support for server-side rendering, which is needed for vite-plugin-wasm to work in Vitest.

I haven't tested this in detail - e.g. whether it will work in a normal Vite SSR context. But I thought it would be good to get early feedback on the approach before investing too much time.

Currently the wasmHelper code tries to load the wasm file through fetch. This only works in a browser context. Even if fetch were available, fetching a relative path would still not work. I believe it should be fairly easy to get it working in a server context as well. One easy fix would be to add an else if clause in the wasmHelper function:

const wasmHelper = async (opts = {}, url: string) => {
  let result: WebAssembly.WebAssemblyInstantiatedSource;
  if (url.startsWith("data:")) {
    // Existing base64 case
  else if (isServer()) {
    // New server case. Wasm file should be loaded from file system.
  } else {
    // Existing fetch case
  }
  return result.instance.exports;
};

The isServer check could be as simple as typeof window === "undefined". However, I could see cases where this would be problematic. Some might have other vite plugins that polyfills window for server contexts etc. Another approach might be to use import.meta.url, and see if it refers to a URL or a file, e.g. import.meta.url.startsWith("file:"). I'm not sure if this would always work, or if it might come with some gotchas.

Are you open to a PR that implements something like this?