Export statement

The export statement is used on module-level definitions, and has two distinct meanings depending on context. If it is succeeded by a string name (e.g. export "Example"), then it is decalring that as an external export of the Wasm module (thus making it accessible to the host via e.g. WasmInstance.exports.Example). Otherwise, it makes the item an export of the Water file, which can be imported in other Water files.

Exporting from a Wasm module

As explained above, the export "Name" syntax can be used on a variety of definitions (e.g. global variables, functions, memories, etc.) to make them accessible from outside the Wasm module. This is used when certain functionality needs to be exposed to the host environment.

For more complete examples, have a look at the examples tab, where it is shown how these exported identifiers can be accessed from the host environment (in this case, Javascript).

Note that classes can not be exported as a whole. However, if they are used as an exception tag, then they can be exported as such. This restriction does not apply for exporting classes from a Water file which can be imported from another Water file.

Exporting from file

This works exactly the same as it does in Javascript/Typescript modules. You can export anything that can be exported to outside the module (described in the previous section), as well as classes.

Like in Javascript, to mark an identifier as a default export, use the `export default ...` syntax.

If some item is exported both out of the Wasm module, and the Water file module, the correct syntax to use is `export "Name" export ...`, and not `export export "Name" ...`. Similarly, for Wasm imports, the correct syntax is `import "Main" "Something" export ...`.

Important note about using memories and tables

Note that if more than one file wants to have access to some memory / table / etc, then it also needs to be exported, and imported into the other files. In other words, memory and table declarations are not necessarily global in Water, even though they might be in raw Wasm.

This decision was made because every other part of Water file modules is only scoped to that file (unless exported and then imported), so this would potentially be an outlier and as such, potentially unexpected behaviour.

Note that certain functions which have an optional memory immediate (e.g. i32.load) would also fail if no memory is imported, even if no memory immediate was provided. When no memory immediate is provided, they default to the first memory declared in that file, which may be coming from an import. Because this might have confusing semantics, avoid using these functions without explicitly providing the memory immediate, unless it is absolutely clear which memory is going to be used.