From 5fd5117cdeda6c6100ce979dbac4dda6a711a759 Mon Sep 17 00:00:00 2001 From: Abiria Date: Sat, 7 Mar 2026 02:05:28 -0500 Subject: [PATCH] docs: fix subtle typos --- docs/docs-contributing-architecture.md | 6 +++--- docs/docs-contributing-complex-data-types.md | 2 +- docs/docs-contributing-testing-locally.md | 4 ++-- docs/docs-using-exports.md | 12 ++++++------ docs/docs-using-extending.md | 6 +++--- docs/docs-using-invoking.md | 4 ++-- docs/docs-using-js-api-support.md | 5 ++--- docs/docs-using-nodejs.md | 4 ++-- 8 files changed, 21 insertions(+), 22 deletions(-) diff --git a/docs/docs-contributing-architecture.md b/docs/docs-contributing-architecture.md index 73aa4398a..6a1d6ea5c 100644 --- 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 index 741f137db..f4f350eed 100644 --- 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 index 469b7f390..ab6913314 100644 --- 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 index 405346e37..4b7ff9d15 100644 --- 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 index 94ee0c058..58d8ef8fc 100644 --- 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 -o ``` 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 index d64f81dd0..0d4c9ef26 100644 --- 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 index 9bd656ca8..6cef2a9cf 100644 --- 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 index c7bacd0d8..cfa1db72b 100644 --- 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.