cloudstructs 0.12.10 → 0.12.11

package/node_modules/@types/keyv/node_modules/@types/node/stream.d.ts

@@ -1,22 +1,3 @@
-/**
- * A stream is an abstract interface for working with streaming data in Node.js.
- * The `node:stream` module provides an API for implementing the stream interface.
- *
- * There are many stream objects provided by Node.js. For instance, a [request to an HTTP server](https://nodejs.org/docs/latest-v25.x/api/http.html#class-httpincomingmessage)
- * and [`process.stdout`](https://nodejs.org/docs/latest-v25.x/api/process.html#processstdout) are both stream instances.
- *
- * Streams can be readable, writable, or both. All streams are instances of [`EventEmitter`](https://nodejs.org/docs/latest-v25.x/api/events.html#class-eventemitter).
- *
- * To access the `node:stream` module:
- *
- * ```js
- * import stream from 'node:stream';
- * ```
- *
- * The `node:stream` module is useful for creating new types of stream instances.
- * It is usually not necessary to use the `node:stream` module to consume streams.
- * @see [source](https://github.com/nodejs/node/blob/v25.x/lib/stream.js)
- */
 declare module "node:stream" {
     import { Blob } from "node:buffer";
     import { Abortable, EventEmitter } from "node:events";
@@ -899,11 +880,20 @@ declare module "node:stream" {
              * @since v0.9.4
              * @param chunk Optional data to write. For streams not operating in object mode, `chunk` must be a {string}, {Buffer},
              * {TypedArray} or {DataView}. For object mode streams, `chunk` may be any JavaScript value other than `null`.
-             * @param [encoding='utf8'] The encoding, if `chunk` is a string.
              * @param callback Callback for when this chunk of data is flushed.
              * @return `false` if the stream wishes for the calling code to wait for the `'drain'` event to be emitted before continuing to write additional data; otherwise `true`.
              */
             write(chunk: any, callback?: (error: Error | null | undefined) => void): boolean;
+            /**
+             * Writes data to the stream, with an explicit encoding for string data.
+             * @see {@link Writable.write} for full details.
+             * @since v0.9.4
+             * @param chunk Optional data to write. For streams not operating in object mode, `chunk` must be a {string}, {Buffer},
+             * {TypedArray} or {DataView}. For object mode streams, `chunk` may be any JavaScript value other than `null`.
+             * @param encoding The encoding, if `chunk` is a string.
+             * @param callback Callback for when this chunk of data is flushed.
+             * @return `false` if the stream wishes for the calling code to wait for the `'drain'` event to be emitted before continuing to write additional data; otherwise `true`.
+             */
             write(chunk: any, encoding: BufferEncoding, callback?: (error: Error | null | undefined) => void): boolean;
             /**
              * The `writable.setDefaultEncoding()` method sets the default `encoding` for a `Writable` stream.
@@ -928,13 +918,27 @@ declare module "node:stream" {
              * // Writing more now is not allowed!
              * ```
              * @since v0.9.4
+             * @param cb Callback for when the stream is finished.
+             */
+            end(cb?: () => void): this;
+            /**
+             * Signals that no more data will be written, with one final chunk of data.
+             * @see {@link Writable.end} for full details.
+             * @since v0.9.4
              * @param chunk Optional data to write. For streams not operating in object mode, `chunk` must be a {string}, {Buffer},
              * {TypedArray} or {DataView}. For object mode streams, `chunk` may be any JavaScript value other than `null`.
-             * @param encoding The encoding if `chunk` is a string
-             * @param callback Callback for when the stream is finished.
+             * @param cb Callback for when the stream is finished.
              */
-            end(cb?: () => void): this;
             end(chunk: any, cb?: () => void): this;
+            /**
+             * Signals that no more data will be written, with one final chunk of data.
+             * @see {@link Writable.end} for full details.
+             * @since v0.9.4
+             * @param chunk Optional data to write. For streams not operating in object mode, `chunk` must be a {string}, {Buffer},
+             * {TypedArray} or {DataView}. For object mode streams, `chunk` may be any JavaScript value other than `null`.
+             * @param encoding The encoding if `chunk` is a string
+             * @param cb Callback for when the stream is finished.
+             */
             end(chunk: any, encoding: BufferEncoding, cb?: () => void): this;
             /**
              * The `writable.cork()` method forces all written data to be buffered in memory.

package/node_modules/@types/keyv/node_modules/@types/node/string_decoder.d.ts

@@ -1,43 +1,3 @@
-/**
- * The `node:string_decoder` module provides an API for decoding `Buffer` objects
- * into strings in a manner that preserves encoded multi-byte UTF-8 and UTF-16
- * characters. It can be accessed using:
- *
- * ```js
- * import { StringDecoder } from 'node:string_decoder';
- * ```
- *
- * The following example shows the basic use of the `StringDecoder` class.
- *
- * ```js
- * import { StringDecoder } from 'node:string_decoder';
- * const decoder = new StringDecoder('utf8');
- *
- * const cent = Buffer.from([0xC2, 0xA2]);
- * console.log(decoder.write(cent)); // Prints: ¢
- *
- * const euro = Buffer.from([0xE2, 0x82, 0xAC]);
- * console.log(decoder.write(euro)); // Prints: €
- * ```
- *
- * When a `Buffer` instance is written to the `StringDecoder` instance, an
- * internal buffer is used to ensure that the decoded string does not contain
- * any incomplete multibyte characters. These are held in the buffer until the
- * next call to `stringDecoder.write()` or until `stringDecoder.end()` is called.
- *
- * In the following example, the three UTF-8 encoded bytes of the European Euro
- * symbol (`€`) are written over three separate operations:
- *
- * ```js
- * import { StringDecoder } from 'node:string_decoder';
- * const decoder = new StringDecoder('utf8');
- *
- * decoder.write(Buffer.from([0xE2]));
- * decoder.write(Buffer.from([0x82]));
- * console.log(decoder.end(Buffer.from([0xAC]))); // Prints: €
- * ```
- * @see [source](https://github.com/nodejs/node/blob/v25.x/lib/string_decoder.js)
- */
 declare module "node:string_decoder" {
     class StringDecoder {
         constructor(encoding?: BufferEncoding);

package/node_modules/@types/keyv/node_modules/@types/node/test/reporters.d.ts

@@ -1,41 +1,3 @@
-/**
- * The `node:test` module supports passing `--test-reporter`
- * flags for the test runner to use a specific reporter.
- *
- * The following built-reporters are supported:
- *
- * * `spec`
- *   The `spec` reporter outputs the test results in a human-readable format. This
- *   is the default reporter.
- *
- * * `tap`
- *   The `tap` reporter outputs the test results in the [TAP](https://testanything.org/) format.
- *
- * * `dot`
- *   The `dot` reporter outputs the test results in a compact format,
- *   where each passing test is represented by a `.`,
- *   and each failing test is represented by a `X`.
- *
- * * `junit`
- *   The junit reporter outputs test results in a jUnit XML format
- *
- * * `lcov`
- *   The `lcov` reporter outputs test coverage when used with the
- *   `--experimental-test-coverage` flag.
- *
- * The exact output of these reporters is subject to change between versions of
- * Node.js, and should not be relied on programmatically. If programmatic access
- * to the test runner's output is required, use the events emitted by the
- * `TestsStream`.
- *
- * The reporters are available via the `node:test/reporters` module:
- *
- * ```js
- * import { tap, spec, dot, junit, lcov } from 'node:test/reporters';
- * ```
- * @since v19.9.0, v18.17.0
- * @see [source](https://github.com/nodejs/node/blob/v25.x/lib/test/reporters.js)
- */
 declare module "node:test/reporters" {
     import { Transform, TransformOptions } from "node:stream";
     import { EventData } from "node:test";

package/node_modules/@types/keyv/node_modules/@types/node/test.d.ts

@@ -1,83 +1,3 @@
-/**
- * The `node:test` module facilitates the creation of JavaScript tests.
- * To access it:
- *
- * ```js
- * import test from 'node:test';
- * ```
- *
- * This module is only available under the `node:` scheme. The following will not
- * work:
- *
- * ```js
- * import test from 'node:test';
- * ```
- *
- * Tests created via the `test` module consist of a single function that is
- * processed in one of three ways:
- *
- * 1. A synchronous function that is considered failing if it throws an exception,
- * and is considered passing otherwise.
- * 2. A function that returns a `Promise` that is considered failing if the `Promise` rejects, and is considered passing if the `Promise` fulfills.
- * 3. A function that receives a callback function. If the callback receives any
- * truthy value as its first argument, the test is considered failing. If a
- * falsy value is passed as the first argument to the callback, the test is
- * considered passing. If the test function receives a callback function and
- * also returns a `Promise`, the test will fail.
- *
- * The following example illustrates how tests are written using the `test` module.
- *
- * ```js
- * test('synchronous passing test', (t) => {
- *   // This test passes because it does not throw an exception.
- *   assert.strictEqual(1, 1);
- * });
- *
- * test('synchronous failing test', (t) => {
- *   // This test fails because it throws an exception.
- *   assert.strictEqual(1, 2);
- * });
- *
- * test('asynchronous passing test', async (t) => {
- *   // This test passes because the Promise returned by the async
- *   // function is settled and not rejected.
- *   assert.strictEqual(1, 1);
- * });
- *
- * test('asynchronous failing test', async (t) => {
- *   // This test fails because the Promise returned by the async
- *   // function is rejected.
- *   assert.strictEqual(1, 2);
- * });
- *
- * test('failing test using Promises', (t) => {
- *   // Promises can be used directly as well.
- *   return new Promise((resolve, reject) => {
- *     setImmediate(() => {
- *       reject(new Error('this will cause the test to fail'));
- *     });
- *   });
- * });
- *
- * test('callback passing test', (t, done) => {
- *   // done() is the callback function. When the setImmediate() runs, it invokes
- *   // done() with no arguments.
- *   setImmediate(done);
- * });
- *
- * test('callback failing test', (t, done) => {
- *   // When the setImmediate() runs, done() is invoked with an Error object and
- *   // the test fails.
- *   setImmediate(() => {
- *     done(new Error('callback failure'));
- *   });
- * });
- * ```
- *
- * If any tests fail, the process exit code is set to `1`.
- * @since v18.0.0, v16.17.0
- * @see [source](https://github.com/nodejs/node/blob/v25.x/lib/test.js)
- */
 declare module "node:test" {
     import { AssertMethodNames } from "node:assert";
     import { Readable, ReadableEventMap } from "node:stream";
@@ -409,6 +329,13 @@ declare module "node:test" {
              * @default 0
              */
             functionCoverage?: number | undefined;
+            /**
+             * Specify environment variables to be passed along to the test process.
+             * This options is not compatible with `isolation='none'`. These variables will override
+             * those from the main process, and are not merged with `process.env`.
+             * @since v25.6.0
+             */
+            env?: NodeJS.ProcessEnv | undefined;
         }
         interface TestsStreamEventMap extends ReadableEventMap {
             "data": [data: TestEvent];

package/node_modules/@types/keyv/node_modules/@types/node/timers/promises.d.ts

@@ -1,18 +1,3 @@
-/**
- * The `timers/promises` API provides an alternative set of timer functions
- * that return `Promise` objects. The API is accessible via
- * `require('node:timers/promises')`.
- *
- * ```js
- * import {
- *   setTimeout,
- *   setImmediate,
- *   setInterval,
- * } from 'node:timers/promises';
- * ```
- * @since v15.0.0
- * @see [source](https://github.com/nodejs/node/blob/v25.x/lib/timers/promises.js)
- */
 declare module "node:timers/promises" {
     import { TimerOptions } from "node:timers";
     /**

package/node_modules/@types/keyv/node_modules/@types/node/timers.d.ts

@@ -1,13 +1,3 @@
-/**
- * The `timer` module exposes a global API for scheduling functions to
- * be called at some future period of time. Because the timer functions are
- * globals, there is no need to import `node:timers` to use the API.
- *
- * The timer functions within Node.js implement a similar API as the timers API
- * provided by Web Browsers but use a different internal implementation that is
- * built around the Node.js [Event Loop](https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/#setimmediate-vs-settimeout).
- * @see [source](https://github.com/nodejs/node/blob/v25.x/lib/timers.js)
- */
 declare module "node:timers" {
     import { Abortable } from "node:events";
     import * as promises from "node:timers/promises";

package/node_modules/@types/keyv/node_modules/@types/node/tls.d.ts

@@ -1,13 +1,3 @@
-/**
- * The `node:tls` module provides an implementation of the Transport Layer Security
- * (TLS) and Secure Socket Layer (SSL) protocols that is built on top of OpenSSL.
- * The module can be accessed using:
- *
- * ```js
- * import tls from 'node:tls';
- * ```
- * @see [source](https://github.com/nodejs/node/blob/v25.x/lib/tls.js)
- */
 declare module "node:tls" {
     import { NonSharedBuffer } from "node:buffer";
     import { X509Certificate } from "node:crypto";
@@ -200,12 +190,6 @@ declare module "node:tls" {
          * An optional Buffer instance containing a TLS session.
          */
         session?: Buffer | undefined;
-        /**
-         * If true, specifies that the OCSP status request extension will be
-         * added to the client hello and an 'OCSPResponse' event will be
-         * emitted on the socket before establishing a secure communication
-         */
-        requestOCSP?: boolean | undefined;
     }
     interface TLSSocketEventMap extends net.SocketEventMap {
         "keylog": [line: NonSharedBuffer];
@@ -577,6 +561,12 @@ declare module "node:tls" {
          * @default true
          */
         rejectUnauthorized?: boolean | undefined;
+        /**
+         * If true, specifies that the OCSP status request extension will be
+         * added to the client hello and an 'OCSPResponse' event will be
+         * emitted on the socket before establishing a secure communication.
+         */
+        requestOCSP?: boolean | undefined;
     }
     interface TlsOptions extends SecureContextOptions, CommonConnectionOptions, net.ServerOpts {
         /**

package/node_modules/@types/keyv/node_modules/@types/node/trace_events.d.ts

@@ -1,97 +1,3 @@
-/**
- * The `node:trace_events` module provides a mechanism to centralize tracing information
- * generated by V8, Node.js core, and userspace code.
- *
- * Tracing can be enabled with the `--trace-event-categories` command-line flag
- * or by using the `trace_events` module. The `--trace-event-categories` flag
- * accepts a list of comma-separated category names.
- *
- * The available categories are:
- *
- * * `node`: An empty placeholder.
- * * `node.async_hooks`: Enables capture of detailed [`async_hooks`](https://nodejs.org/docs/latest-v25.x/api/async_hooks.html) trace data.
- * The [`async_hooks`](https://nodejs.org/docs/latest-v25.x/api/async_hooks.html) events have a unique `asyncId` and a special `triggerId` `triggerAsyncId` property.
- * * `node.bootstrap`: Enables capture of Node.js bootstrap milestones.
- * * `node.console`: Enables capture of `console.time()` and `console.count()` output.
- * * `node.threadpoolwork.sync`: Enables capture of trace data for threadpool synchronous operations, such as `blob`, `zlib`, `crypto` and `node_api`.
- * * `node.threadpoolwork.async`: Enables capture of trace data for threadpool asynchronous operations, such as `blob`, `zlib`, `crypto` and `node_api`.
- * * `node.dns.native`: Enables capture of trace data for DNS queries.
- * * `node.net.native`: Enables capture of trace data for network.
- * * `node.environment`: Enables capture of Node.js Environment milestones.
- * * `node.fs.sync`: Enables capture of trace data for file system sync methods.
- * * `node.fs_dir.sync`: Enables capture of trace data for file system sync directory methods.
- * * `node.fs.async`: Enables capture of trace data for file system async methods.
- * * `node.fs_dir.async`: Enables capture of trace data for file system async directory methods.
- * * `node.perf`: Enables capture of [Performance API](https://nodejs.org/docs/latest-v25.x/api/perf_hooks.html) measurements.
- *    * `node.perf.usertiming`: Enables capture of only Performance API User Timing
- *    measures and marks.
- *    * `node.perf.timerify`: Enables capture of only Performance API timerify
- *    measurements.
- * * `node.promises.rejections`: Enables capture of trace data tracking the number
- * of unhandled Promise rejections and handled-after-rejections.
- * * `node.vm.script`: Enables capture of trace data for the `node:vm` module's `runInNewContext()`, `runInContext()`, and `runInThisContext()` methods.
- * * `v8`: The [V8](https://nodejs.org/docs/latest-v25.x/api/v8.html) events are GC, compiling, and execution related.
- * * `node.http`: Enables capture of trace data for http request / response.
- *
- * By default the `node`, `node.async_hooks`, and `v8` categories are enabled.
- *
- * ```bash
- * node --trace-event-categories v8,node,node.async_hooks server.js
- * ```
- *
- * Prior versions of Node.js required the use of the `--trace-events-enabled` flag to enable trace events. This requirement has been removed. However, the `--trace-events-enabled` flag _may_ still be
- * used and will enable the `node`, `node.async_hooks`, and `v8` trace event categories by default.
- *
- * ```bash
- * node --trace-events-enabled
- *
- * # is equivalent to
- *
- * node --trace-event-categories v8,node,node.async_hooks
- * ```
- *
- * Alternatively, trace events may be enabled using the `node:trace_events` module:
- *
- * ```js
- * import trace_events from 'node:trace_events';
- * const tracing = trace_events.createTracing({ categories: ['node.perf'] });
- * tracing.enable();  // Enable trace event capture for the 'node.perf' category
- *
- * // do work
- *
- * tracing.disable();  // Disable trace event capture for the 'node.perf' category
- * ```
- *
- * Running Node.js with tracing enabled will produce log files that can be opened
- * in the [`chrome://tracing`](https://www.chromium.org/developers/how-tos/trace-event-profiling-tool) tab of Chrome.
- *
- * The logging file is by default called `node_trace.${rotation}.log`, where `${rotation}` is an incrementing log-rotation id. The filepath pattern can
- * be specified with `--trace-event-file-pattern` that accepts a template
- * string that supports `${rotation}` and `${pid}`:
- *
- * ```bash
- * node --trace-event-categories v8 --trace-event-file-pattern '${pid}-${rotation}.log' server.js
- * ```
- *
- * To guarantee that the log file is properly generated after signal events like `SIGINT`, `SIGTERM`, or `SIGBREAK`, make sure to have the appropriate handlers
- * in your code, such as:
- *
- * ```js
- * process.on('SIGINT', function onSigint() {
- *   console.info('Received SIGINT.');
- *   process.exit(130);  // Or applicable exit code depending on OS and signal
- * });
- * ```
- *
- * The tracing system uses the same time source
- * as the one used by `process.hrtime()`.
- * However the trace-event timestamps are expressed in microseconds,
- * unlike `process.hrtime()` which returns nanoseconds.
- *
- * The features from this module are not available in [`Worker`](https://nodejs.org/docs/latest-v25.x/api/worker_threads.html#class-worker) threads.
- * @experimental
- * @see [source](https://github.com/nodejs/node/blob/v25.x/lib/trace_events.js)
- */
 declare module "node:trace_events" {
     /**
      * The `Tracing` object is used to enable or disable tracing for sets of

package/node_modules/@types/keyv/node_modules/@types/node/ts5.6/buffer.buffer.d.ts

@@ -172,7 +172,7 @@ declare module "node:buffer" {
              * If `totalLength` is not provided, it is calculated from the `Buffer` instances
              * in `list` by adding their lengths.
              *
-             * If `totalLength` is provided, it is coerced to an unsigned integer. If the
+             * If `totalLength` is provided, it must be an unsigned integer. If the
              * combined length of the `Buffer`s in `list` exceeds `totalLength`, the result is
              * truncated to `totalLength`.
              *

package/node_modules/@types/keyv/node_modules/@types/node/tty.d.ts

@@ -1,28 +1,3 @@
-/**
- * The `node:tty` module provides the `tty.ReadStream` and `tty.WriteStream` classes. In most cases, it will not be necessary or possible to use this module
- * directly. However, it can be accessed using:
- *
- * ```js
- * import tty from 'node:tty';
- * ```
- *
- * When Node.js detects that it is being run with a text terminal ("TTY")
- * attached, `process.stdin` will, by default, be initialized as an instance of `tty.ReadStream` and both `process.stdout` and `process.stderr` will, by
- * default, be instances of `tty.WriteStream`. The preferred method of determining
- * whether Node.js is being run within a TTY context is to check that the value of
- * the `process.stdout.isTTY` property is `true`:
- *
- * ```console
- * $ node -p -e "Boolean(process.stdout.isTTY)"
- * true
- * $ node -p -e "Boolean(process.stdout.isTTY)" | cat
- * false
- * ```
- *
- * In most cases, there should be little to no reason for an application to
- * manually create instances of the `tty.ReadStream` and `tty.WriteStream` classes.
- * @see [source](https://github.com/nodejs/node/blob/v25.x/lib/tty.js)
- */
 declare module "node:tty" {
     import * as net from "node:net";
     /**

package/node_modules/@types/keyv/node_modules/@types/node/url.d.ts

@@ -1,12 +1,3 @@
-/**
- * The `node:url` module provides utilities for URL resolution and parsing. It can
- * be accessed using:
- *
- * ```js
- * import url from 'node:url';
- * ```
- * @see [source](https://github.com/nodejs/node/blob/v25.x/lib/url.js)
- */
 declare module "node:url" {
     import { Blob, NonSharedBuffer } from "node:buffer";
     import { ClientRequestArgs } from "node:http";

package/node_modules/@types/keyv/node_modules/@types/node/util.d.ts

@@ -1,13 +1,3 @@
-/**
- * The `node:util` module supports the needs of Node.js internal APIs. Many of the
- * utilities are useful for application and module developers as well. To access
- * it:
- *
- * ```js
- * import util from 'node:util';
- * ```
- * @see [source](https://github.com/nodejs/node/blob/v25.x/lib/util.js)
- */
 declare module "node:util" {
     export * as types from "node:util/types";
     export type InspectStyle =

package/node_modules/@types/keyv/node_modules/@types/node/v8.d.ts

@@ -1,11 +1,3 @@
-/**
- * The `node:v8` module exposes APIs that are specific to the version of [V8](https://developers.google.com/v8/) built into the Node.js binary. It can be accessed using:
- *
- * ```js
- * import v8 from 'node:v8';
- * ```
- * @see [source](https://github.com/nodejs/node/blob/v25.x/lib/v8.js)
- */
 declare module "node:v8" {
     import { NonSharedBuffer } from "node:buffer";
     import { Readable } from "node:stream";

package/node_modules/@types/keyv/node_modules/@types/node/vm.d.ts

@@ -1,41 +1,3 @@
-/**
- * The `node:vm` module enables compiling and running code within V8 Virtual
- * Machine contexts.
- *
- * **The `node:vm` module is not a security**
- * **mechanism. Do not use it to run untrusted code.**
- *
- * JavaScript code can be compiled and run immediately or
- * compiled, saved, and run later.
- *
- * A common use case is to run the code in a different V8 Context. This means
- * invoked code has a different global object than the invoking code.
- *
- * One can provide the context by `contextifying` an
- * object. The invoked code treats any property in the context like a
- * global variable. Any changes to global variables caused by the invoked
- * code are reflected in the context object.
- *
- * ```js
- * import vm from 'node:vm';
- *
- * const x = 1;
- *
- * const context = { x: 2 };
- * vm.createContext(context); // Contextify the object.
- *
- * const code = 'x += 40; var y = 17;';
- * // `x` and `y` are global variables in the context.
- * // Initially, x has the value 2 because that is the value of context.x.
- * vm.runInContext(code, context);
- *
- * console.log(context.x); // 42
- * console.log(context.y); // 17
- *
- * console.log(x); // 1; y is not defined.
- * ```
- * @see [source](https://github.com/nodejs/node/blob/v25.x/lib/vm.js)
- */
 declare module "node:vm" {
     import { NonSharedBuffer } from "node:buffer";
     import { ImportAttributes, ImportPhase } from "node:module";

package/node_modules/@types/keyv/node_modules/@types/node/wasi.d.ts

@@ -1,74 +1,3 @@
-/**
- * **The `node:wasi` module does not currently provide the**
- * **comprehensive file system security properties provided by some WASI runtimes.**
- * **Full support for secure file system sandboxing may or may not be implemented in**
- * **future. In the mean time, do not rely on it to run untrusted code.**
- *
- * The WASI API provides an implementation of the [WebAssembly System Interface](https://wasi.dev/) specification. WASI gives WebAssembly applications access to the underlying
- * operating system via a collection of POSIX-like functions.
- *
- * ```js
- * import { readFile } from 'node:fs/promises';
- * import { WASI } from 'node:wasi';
- * import { argv, env } from 'node:process';
- *
- * const wasi = new WASI({
- *   version: 'preview1',
- *   args: argv,
- *   env,
- *   preopens: {
- *     '/local': '/some/real/path/that/wasm/can/access',
- *   },
- * });
- *
- * const wasm = await WebAssembly.compile(
- *   await readFile(new URL('./demo.wasm', import.meta.url)),
- * );
- * const instance = await WebAssembly.instantiate(wasm, wasi.getImportObject());
- *
- * wasi.start(instance);
- * ```
- *
- * To run the above example, create a new WebAssembly text format file named `demo.wat`:
- *
- * ```text
- * (module
- *     ;; Import the required fd_write WASI function which will write the given io vectors to stdout
- *     ;; The function signature for fd_write is:
- *     ;; (File Descriptor, *iovs, iovs_len, nwritten) -> Returns number of bytes written
- *     (import "wasi_snapshot_preview1" "fd_write" (func $fd_write (param i32 i32 i32 i32) (result i32)))
- *
- *     (memory 1)
- *     (export "memory" (memory 0))
- *
- *     ;; Write 'hello world\n' to memory at an offset of 8 bytes
- *     ;; Note the trailing newline which is required for the text to appear
- *     (data (i32.const 8) "hello world\n")
- *
- *     (func $main (export "_start")
- *         ;; Creating a new io vector within linear memory
- *         (i32.store (i32.const 0) (i32.const 8))  ;; iov.iov_base - This is a pointer to the start of the 'hello world\n' string
- *         (i32.store (i32.const 4) (i32.const 12))  ;; iov.iov_len - The length of the 'hello world\n' string
- *
- *         (call $fd_write
- *             (i32.const 1) ;; file_descriptor - 1 for stdout
- *             (i32.const 0) ;; *iovs - The pointer to the iov array, which is stored at memory location 0
- *             (i32.const 1) ;; iovs_len - We're printing 1 string stored in an iov - so one.
- *             (i32.const 20) ;; nwritten - A place in memory to store the number of bytes written
- *         )
- *         drop ;; Discard the number of bytes written from the top of the stack
- *     )
- * )
- * ```
- *
- * Use [wabt](https://github.com/WebAssembly/wabt) to compile `.wat` to `.wasm`
- *
- * ```bash
- * wat2wasm demo.wat
- * ```
- * @experimental
- * @see [source](https://github.com/nodejs/node/blob/v25.x/lib/wasi.js)
- */
 declare module "node:wasi" {
     interface WASIOptions {
         /**