bytecodealliance · saulecabrera · Mar 7, 2026 · Mar 7, 2026
diff --git a/docs/docs-contributing-architecture.md b/docs/docs-contributing-architecture.md
@@ -106,7 +106,7 @@ by a Cargo feature on a case-by-case basis.
 
 The CLI that drives the `javy-codegen` crate to compile JS to Wasm. This
 isn't intended to be a CLI that accommodates all uses for all users but
-rather to provide a useful base of functionality. 
+rather to provide a useful base of functionality.
 
 #### When to add a `cargo` feature
 
@@ -128,13 +128,13 @@ A Rust crate for compiling JS to Wasm.
 ### `javy-plugin-processing`
 
 Contains the logic for initializing a Javy plugin. Used to build the default
-plugin and also be the Javy CLI for its plugin initialization logic.
+plugin and also by the Javy CLI for its plugin initialization logic.
 
 ### `javy-plugin`
 
 Gets compiled to `plugin.wasm` for use by the CLI and in environments for
 running dynamically linked modules. This is the default plugin for Javy.
-This isn't intended to be used as a code library by third parties. Defines a
+This isn't intended to be used as a code library by third parties. Defines
 an `initialize_runtime` function that uses a configuration structure to
 allow the CLI to set various JS runtime configuration options.
 

diff --git a/docs/docs-contributing-complex-data-types.md b/docs/docs-contributing-complex-data-types.md
@@ -22,7 +22,7 @@ encoded to a JSON string and that string can be passed by encoding it into
 a UTF-8 byte array and using the previous solution. Other serialization formats
 can also be used to encode the structured data to a byte array.
 
-The examples below use Rust and Wasmtime to on the host however any programming
+The examples below use Rust and Wasmtime on the host; however, any programming
 language and WebAssembly runtime should support using the same approach.
 
 ## For exported functions

diff --git a/docs/docs-contributing-testing-locally.md b/docs/docs-contributing-testing-locally.md
@@ -3,8 +3,8 @@
 1. Clone submodules
 
 ```
-git submodules init
-git submodules update
+git submodule init
+git submodule update
 ```
 
 2. Install cargo hack

diff --git a/docs/docs-using-exports.md b/docs/docs-using-exports.md
@@ -1,7 +1,7 @@
 # Exporting JavaScript functions through WebAssembly
 
 To export exported JavaScript functions, you can pass a `.wit` file and `wit` world
-when running `javy build`. 
+when running `javy build`.
 
 Only ESM exports are supported (that is, Node.js/CommonJS exports are _not_
 supported). For each exported JavaScript function, Javy will add an additional
@@ -26,7 +26,7 @@ console.log("Hello world!");
 package local:main;
 
 world index-world {
-  export foo: func(); 
+  export foo: func();
 }
 ```
 
@@ -48,7 +48,7 @@ build`.
 
 ## Exports with multiple words
 
-Exported function names with multiple words have to written in kebab-case in the
+Exported function names with multiple words have to be written in kebab-case in the
 `.wit` file (a restriction imposed by `wit`), they are exported from the Wasm
 module as kebab-case to match the WIT, and Javy will match the WIT export to
 a JavaScript export with the same name but in camel-case.
@@ -65,11 +65,11 @@ export function fooBar() {
 package local:main;
 
 world index {
-  export foo-bar: func(); 
+  export foo-bar: func();
 }
 ```
 
-Run: 
+Run:
 
 ```bash
 $ javy build index.js -C wit=index.wit -C wit-world=index -o index.wasm
@@ -95,7 +95,7 @@ export default function () {
 package local:main;
 
 world index {
-  export default: func(); 
+  export default: func();
 }
 ```
 

diff --git a/docs/docs-using-extending.md b/docs/docs-using-extending.md
@@ -15,7 +15,7 @@ converted to Wasm modules during the initialization process.
 
 You should write your plugin as a WASI preview 1 plugin if you want to use WASI
 preview 1 APIs to interact with modules generated with your plugin. These APIs
-include reading from standard input and writing to standard output or standard 
+include reading from standard input and writing to standard output or standard
 error. The drawback to using WASI preview 1 is support may not continue to be
 available in various tools because this is a preview API and maintainers for
 some tools and the Rust toolchain may opt to discontinue support.
@@ -88,7 +88,7 @@ javy init-plugin <path_to_plugin> -o <path_to_initialized_module>
 ```
 
 which will validate and initialize the Javy runtime. This `javy init-plugin`
-step is required for the plugin to be useable by the Javy CLI.
+step is required for the plugin to be usable by the Javy CLI.
 
 See our documentation on [using complex data types in Wasm
 functions](./contributing-complex-data-types.md) for how to support Wasm
@@ -223,7 +223,7 @@ export!(Component);
 
 fn config() -> Config {
     Config::default()
-    
+
 }
 
 fn modify_runtime(runtime: Runtime) -> Runtime {

diff --git a/docs/docs-using-invoking.md b/docs/docs-using-invoking.md
@@ -1,10 +1,10 @@
-### Invoking modules programatically
+### Invoking modules programmatically
 
 Javy-generated modules are by design WASI only and follow the [command
 pattern](https://github.com/WebAssembly/WASI/blob/snapshot-01/design/application-abi.md#current-unstable-abi).
 
 Any input must be passed via `stdin` and any output will be placed in `stdout`.
-This is especially important when invoking Javy modules from a custom embedding. 
+This is especially important when invoking Javy modules from a custom embedding.
 
 In a runtime like Wasmtime, [wasmtime-wasi](
 https://docs.rs/wasmtime-wasi/latest/wasmtime_wasi/struct.WasiCtx.html#method.set_stdin)

diff --git a/docs/docs-using-js-api-support.md b/docs/docs-using-js-api-support.md
@@ -15,10 +15,9 @@ explicitly marked as partially supported in the table below.
 
 |API|Support|Comments|
 |:-:|:-:|:-:|
-|`JSON`|✅| Improved performace through SIMD JSON, when using the `-J simd-json-builtins` flag|
+|`JSON`|✅| Improved performance through SIMD JSON, when using the `-J simd-json-builtins` flag|
 |`String.prototype.normalize`|✅| |
-|`TexDecoder`|🚧| Partial support, not fully compliant|
-|`TextEncoder`|🚧| Partial support, not fully compliant|
+|`TextDecoder`|🚧| Partial support, not fully compliant|
 |`TextEncoder`|🚧| Partial support, not fully compliant|
 |`console`|🚧| Partial support, `console.log` and `console.error`|
 

diff --git a/docs/docs-using-nodejs.md b/docs/docs-using-nodejs.md
@@ -4,7 +4,7 @@ This example demonstrates how to run Javy in a Node.js (v20+) host application.
 ## Warning
 This example does NOT show how to run a Node.js application in Javy. This is
 useful for when you want to run untrusted user generated code in a sandbox. This
-code is meant to be an example not production-ready code. 
+code is meant to be an example not production-ready code.
 
 It's also important to note that the WASI implementation in NodeJS is currently
 considered [experimental].
@@ -13,7 +13,7 @@ considered [experimental].
 
 ## Summary
 This example shows how to use a dynamically linked Javy compiled Wasm module. We
-use std in/out/error to communicate with the embedded javascript see [this blog
+use std in/out/error to communicate with the embedded javascript. See [this blog
 post](https://k33g.hashnode.dev/wasi-communication-between-nodejs-and-wasm-modules-another-way-with-stdin-and-stdout)
 for details.