@effect/platform-node-shared 4.0.0-beta.70 → 4.0.0-beta.71

package/src/NodePath.ts

@@ -1,17 +1,26 @@
 /**
- * Shared Node-compatible implementation of Effect's `Path` service.
+ * Node-backed provider for Effect's `Path` service.
  *
- * This module adapts Node's `node:path` and `node:url` APIs into layers that
- * can be provided to Effect programs needing path manipulation, such as
- * resolving configuration files, building file system locations, parsing
- * names and extensions, or converting between file paths and `file:` URLs.
+ * This module turns Node's `node:path` and `node:url` APIs into `Layer`s for
+ * programs that depend on `Path`. Use it when code should receive path
+ * operations from the Effect environment instead of importing `node:path`
+ * directly, including configuration loading, filesystem composition, and file
+ * URL conversion.
  *
- * The default layer follows the host platform semantics exposed by
- * `node:path`, while `layerPosix` and `layerWin32` provide stable POSIX or
- * Windows behavior regardless of the current runtime. Path operations are
- * syntactic and do not check whether files exist; separators, drive letters,
- * UNC paths, and URL encoding rules can also differ by platform. Invalid
- * file URL conversions are reported through `BadArgument`.
+ * **Mental model**
+ *
+ * `layer` follows the platform semantics of the current Node runtime. The
+ * `layerPosix` and `layerWin32` variants pin the syntax rules to POSIX or
+ * Windows, which is useful for deterministic parsing, formatting, and tests.
+ * All three layers include `fromFileUrl` and `toFileUrl` behavior backed by
+ * Node's URL conversion functions.
+ *
+ * **Gotchas**
+ *
+ * Path operations are syntactic: they normalize separators, roots, drive
+ * letters, UNC segments, extensions, and relative segments without checking the
+ * filesystem. File URL conversion follows Node's validation and encoding
+ * rules, and invalid conversions fail with `BadArgument`.
  *
  * @since 4.0.0
  */

package/src/NodeRuntime.ts

@@ -1,20 +1,32 @@
 /**
- * Shared runtime helpers for running Effect programs as Node-compatible
- * process entry points.
+ * Node-compatible process runner for Effect programs.
  *
- * This module provides the common `runMain` implementation used by
- * Node-compatible platform packages. It is intended for CLIs, scripts,
- * workers, servers, and other process-oriented programs that should run an
- * Effect as their main fiber while still following Node process conventions.
+ * This module provides the shared `runMain` implementation used by
+ * Node-compatible platform packages. Use it at the outer edge of a CLI, script,
+ * worker, server, or test harness when a single Effect should become the main
+ * fiber for the process while still following Node signal and exit-code
+ * conventions.
  *
- * The runner installs `SIGINT` and `SIGTERM` handlers for the lifetime of the
- * main fiber, translating those process signals into fiber interruption so
- * Effect finalizers and the configured teardown can run. When the fiber exits,
- * the signal listeners are removed and teardown determines the exit code. Clean
- * success lets the Node event loop drain naturally instead of forcing
- * `process.exit(0)`, while signal-triggered or non-zero exits call
- * `process.exit` after teardown, so long-running resources should be modeled
- * in the Effect scope and finalized explicitly.
+ * **Mental model**
+ *
+ * `runMain` starts the supplied Effect as the process root. While that fiber is
+ * running, `SIGINT` and `SIGTERM` are translated into fiber interruption so
+ * scoped resources and finalizers get a chance to run. After the fiber exits,
+ * the signal listeners are removed and the configured teardown decides the
+ * process exit code.
+ *
+ * **Common tasks**
+ *
+ * - Launch a command-line program or long-running service from an Effect.
+ * - Share the same main-runner behavior across Node-compatible packages.
+ * - Customize teardown or runtime error reporting with the `runMain` options.
+ *
+ * **Gotchas**
+ *
+ * Clean success lets the Node event loop drain naturally instead of forcing
+ * `process.exit(0)`. Signal-triggered interruption or a non-zero teardown code
+ * calls `process.exit`, so long-lived handles should be acquired in Effect
+ * scopes and released by finalizers.
  *
  * @since 4.0.0
  */

package/src/NodeSink.ts

@@ -1,20 +1,35 @@
 /**
  * Sink adapters for writing Effect stream chunks into Node writable streams.
  *
- * This module is used at the boundary where Effect `Stream`s or `Channel`s need
- * to push data into Node's writable side: file streams, HTTP request or
- * response bodies, process stdio, sockets, and transform inputs such as
- * compression or encryption streams. It exposes both a `Sink` constructor for
- * ordinary stream pipelines and lower-level `Channel` and pull helpers used by
- * other Node stream adapters.
+ * This module is the writable-stream boundary for Node APIs: push Effect
+ * `Stream` or `Channel` chunks into file streams, HTTP request or response
+ * bodies, process stdio, sockets, and transform inputs such as compression or
+ * encryption streams. It exposes a `Sink` constructor for ordinary stream
+ * pipelines plus lower-level `Channel` and pull helpers used by other Node
+ * stream adapters.
  *
- * The implementation follows Node writable semantics. Chunks are written in
- * order; when `write` returns `false`, pulling pauses until `drain` so upstream
+ * **Mental model**
+ *
+ * {@link fromWritable} builds a `Sink` for normal stream pipelines.
+ * {@link fromWritableChannel} exposes the same bridge as a `Channel`, and
+ * {@link pullIntoWritable} is the lower-level loop for adapters that already
+ * have a pull and a Node writable. All three write chunks in order and follow
+ * Node writable backpressure.
+ *
+ * **Common tasks**
+ *
+ * Use {@link fromWritable} to pipe an Effect stream into a Node destination.
+ * Use {@link fromWritableChannel} when composing at the `Channel` level. Use
+ * {@link pullIntoWritable} inside custom Node stream adapters that need direct
+ * control over the upstream pull.
+ *
+ * **Gotchas**
+ *
+ * When `write` returns `false`, pulling pauses until `drain` so upstream
  * producers do not overrun the writable buffer. Writable `error` events are
  * mapped through `onError`, and the writable is ended and awaited via `finish`
  * when upstream completes unless `endOnDone` is `false`. Use `endOnDone: false`
- * for externally owned or long-lived writables, and make sure `onError` keeps
- * Node's untyped errors meaningful for the calling Effect workflow.
+ * for externally owned or long-lived writables.
  *
  * @since 4.0.0
  */

package/src/NodeSocket.ts

@@ -1,17 +1,27 @@
 /**
- * Shared Node socket constructors for adapting `node:net` connections and
- * other Node `Duplex` streams to Effect's `Socket.Socket` interface.
+ * Node socket adapters for Effect sockets.
  *
- * Use this module when building TCP clients, Unix domain socket clients, or
- * higher-level protocols that already expose a Node `Duplex`. Connections are
- * scoped, so finalizers close or destroy the underlying stream, open timeouts
- * are reported as socket open errors, and Node read, write, and close events
- * are translated into `SocketError` values.
+ * This module opens `node:net` connections or wraps existing Node `Duplex`
+ * streams and presents them as `Socket.Socket` values, socket channels, or
+ * layers. It is the low-level bridge for TCP clients, Unix domain socket
+ * clients, and protocols that already expose a Node duplex stream.
  *
- * Node sockets have a few operational details worth keeping in mind: Unix
- * socket paths are supplied through `NetConnectOpts.path`, writes complete only
- * after Node accepts or flushes the chunk, and abnormal close events are
- * surfaced as close errors while normal remote ends complete the socket run.
+ * **Mental model**
+ *
+ * A socket acquired here is scoped. `makeNet` dials with
+ * `net.createConnection`, `fromDuplex` adapts any duplex returned by an Effect,
+ * `makeNetChannel` exposes the socket as a `Channel`, and `layerNet` provides
+ * it through the Effect environment. While a socket handler is running,
+ * `NetSocket` gives access to the underlying Node `net.Socket` for cases that
+ * need Node-specific operations.
+ *
+ * **Gotchas**
+ *
+ * `openTimeout` only limits opening the connection. Writes complete when Node
+ * accepts or flushes a chunk, close events are translated to `SocketError`
+ * values, and finalizers close or destroy the stream when the surrounding scope
+ * ends. Unix socket paths are supplied through `NetConnectOpts.path`, so use
+ * the same platform path rules as Node.
  *
  * @since 4.0.0
  */

package/src/NodeSocketServer.ts

@@ -1,20 +1,38 @@
 /**
- * Shared Node socket server constructors for exposing `node:net` servers and
- * `ws` WebSocket servers as Effect `SocketServer.SocketServer` services.
+ * Node socket server adapters for Effect's unstable socket server API.
  *
- * Use this module when implementing TCP services, Unix domain socket services,
- * WebSocket endpoints, or higher-level protocols such as RPC transports that
- * need to accept incoming connections through Effect's socket APIs. TCP
- * connections are adapted through `NodeSocket.fromDuplex`, while WebSocket
- * handlers also receive the underlying `WebSocket` and Node `IncomingMessage`
- * in their fiber context.
+ * This module turns `node:net` TCP or Unix-domain servers and `ws` WebSocket
+ * servers into scoped `SocketServer.SocketServer` services. Use the TCP
+ * constructors when handlers should receive a `Socket.Socket` backed by a Node
+ * `net.Socket`; use the WebSocket constructors when handlers should receive a
+ * `Socket.Socket` backed by `ws` and have access to the per-connection
+ * WebSocket and `IncomingMessage` services.
  *
- * The server starts listening before the constructor returns, and the exported
- * `address` is derived from the actual Node server after binding. Prefer that
- * address when using port `0`, wildcard hosts, or Unix socket paths. Incoming
- * connections accepted before `run` is installed are queued and then handed to
- * the handler, each `run` call owns the scope for its connection fibers, and
- * the enclosing scope closes the underlying Node server.
+ * **Mental model**
+ *
+ * Calling {@link make} or {@link makeWebSocket} starts the underlying server in
+ * the current scope and returns the bound address. `run` installs the
+ * connection handler for that server, forks each accepted connection into a
+ * child scope, and closes those fibers when `run` finalizes. Connections
+ * accepted before `run` is installed are queued and then handed to the handler.
+ *
+ * **Common tasks**
+ *
+ * - Bind TCP ports or Unix socket paths with {@link make} or {@link layer}.
+ * - Expose `ws` WebSocket endpoints with {@link makeWebSocket} or
+ *   {@link layerWebSocket}.
+ * - Read the returned `address` after binding port `0` or a wildcard host.
+ * - Inspect `NodeSocket.NetSocket`, `Socket.WebSocket`, or
+ *   {@link IncomingMessage} from handler context when lower-level details are
+ *   needed.
+ *
+ * **Gotchas**
+ *
+ * A constructor listens before it returns, so open errors fail construction
+ * rather than the first `run`. The server lifetime belongs to the scope that
+ * created it, while each `run` call owns its connection fibers. WebSocket
+ * handlers run with the `ws` connection and Node request in context, but TCP
+ * handlers expose only the underlying Node socket context.
  *
  * @since 4.0.0
  */

package/src/NodeStdio.ts

@@ -1,19 +1,34 @@
 /**
  * Shared Node.js implementation of the Effect `Stdio` service.
  *
- * This module builds the `Stdio` layer used by Node platform packages by
- * wiring the service to the current process: command-line arguments come from
- * `process.argv`, input is read from `process.stdin`, and output and error
- * output are written to `process.stdout` and `process.stderr`. It is intended
- * for CLIs, scripts, command runners, test harnesses, and other
- * process-oriented programs that need standard I/O through Effect services.
+ * `NodeStdio` provides {@link Stdio.Stdio} from the current Node process. The
+ * exported {@link layer} reads command-line arguments from `process.argv`,
+ * consumes input from `process.stdin`, and writes normal and error output to
+ * `process.stdout` and `process.stderr`. It is the shared implementation used
+ * by Node platform packages for CLIs, scripts, command runners, test harnesses,
+ * and other process-oriented programs.
  *
- * The process stdio streams are global resources owned by Node. This layer
- * leaves stdin open and does not end stdout or stderr by default, avoiding
- * accidental closure of handles other code in the process may still use. Those
- * streams may be pipes, files, or TTYs; interactive terminal behavior such as
- * raw mode, echo, colors, and cursor movement should be coordinated with the
- * terminal APIs instead of assuming this layer has exclusive control.
+ * **Mental model**
+ *
+ * Application code should depend on `Stdio`; this module decides that the
+ * backing resources are the global Node process handles. The layer does not
+ * create new streams and does not claim exclusive ownership of the existing
+ * ones.
+ *
+ * **Common tasks**
+ *
+ * Use {@link layer} when an Effect program needs process arguments, stdin,
+ * stdout, or stderr through the service environment. Pair it with terminal
+ * services when the same program also needs line editing, raw key input, or
+ * terminal dimensions.
+ *
+ * **Gotchas**
+ *
+ * Process stdio streams are shared with the rest of the Node process. This
+ * layer leaves stdin open and does not end stdout or stderr by default, avoiding
+ * accidental closure of handles that other code may still use. The streams may
+ * be pipes, files, or TTYs; terminal-specific behavior such as raw mode, echo,
+ * color detection, and cursor movement belongs with terminal APIs.
  *
  * @since 4.0.0
  */

package/src/NodeStream.ts

@@ -1,19 +1,28 @@
 /**
- * Interoperability between Node streams and Effect streams and channels.
+ * Adapters between Node streams and Effect streams, channels, and readables.
  *
- * This module adapts `Readable` and `Duplex` instances at the boundary with
- * Node APIs: wrapping sources such as files, HTTP responses, child process
- * output, and compression transforms as Effect `Stream`s or `Channel`s, piping
- * Effect streams through Node duplex transforms, exposing an Effect `Stream`
- * back to Node as a `Readable`, and collecting small readable payloads into
- * strings or binary buffers.
+ * This module is the stream boundary for Node APIs: wrap `Readable` or
+ * `Duplex` values as Effect `Stream`s and `Channel`s, pipe an Effect stream
+ * through a Node duplex transform, expose an Effect `Stream` back to Node as a
+ * `Readable`, or collect bounded readable payloads into strings, array
+ * buffers, and `Uint8Array`s. Common sources include files, HTTP bodies, child
+ * process stdio, sockets, and compression or crypto transforms.
  *
- * The adapters preserve the Node stream semantics that matter for production
- * code. Writes wait for `drain` when a writable side applies backpressure,
- * readable streams are destroyed on scope finalization by default, and stream
- * failures are routed through `onError` or `Cause.UnknownError`. For long-lived
- * or externally owned streams, pass `closeOnDone` or `endOnDone` carefully, and
- * use `maxBytes` on collection helpers to avoid buffering unbounded input.
+ * **Mental model**
+ *
+ * Read adapters pull from Node's readable side into Effect. Duplex adapters
+ * write upstream Effect chunks to Node while reading transformed chunks back.
+ * `toReadable` runs an Effect stream from the caller's context, while
+ * `toReadableNever` is for streams that need no services.
+ *
+ * **Gotchas**
+ *
+ * Node backpressure is preserved: writes pause until `drain` before more input
+ * is pulled. Readables are destroyed on scope finalization by default, and
+ * duplex writable sides are ended when upstream completes unless configured
+ * otherwise. For externally owned or long-lived streams, choose `closeOnDone`
+ * and `endOnDone` deliberately; for collection helpers, set `maxBytes` when
+ * input size is not already bounded.
  *
  * @since 4.0.0
  */

package/src/NodeTerminal.ts

@@ -1,17 +1,30 @@
 /**
  * Shared Node.js implementation of Effect's `Terminal` service.
  *
- * This module is the process-backed terminal implementation used by Node
- * platform packages. It adapts Node's `readline` APIs and the current
- * process' `stdin` and `stdout` streams into a `Terminal`, making it suitable
- * for CLIs, REPLs, prompts, full-screen terminal programs, and other
- * command-line tools that need line input, keypress input, terminal
- * dimensions, or prompt output.
+ * `NodeTerminal` adapts Node's `readline` APIs plus the current process'
+ * `stdin` and `stdout` streams into {@link Terminal.Terminal}. It is the shared
+ * process-backed terminal used by Node platform packages for prompts, REPLs,
+ * command-line tools, and interactive programs that need line input, key input,
+ * terminal dimensions, or display output.
  *
- * The implementation works with global process streams, so callers should
- * acquire it with a scope or provide `layer` to ensure cleanup. When `stdin`
- * is a TTY, raw mode is enabled while the scoped readline interface is active
- * and restored on release; raw mode changes how keys are delivered and can
+ * **Mental model**
+ *
+ * {@link make} creates a scoped terminal around the global process streams, and
+ * {@link layer} provides that terminal with the default quit behavior for key
+ * input. While the scope is active, the module owns the Node `readline`
+ * interface it created; it does not own the process streams themselves.
+ *
+ * **Common tasks**
+ *
+ * Use {@link make} when a custom `shouldQuit` predicate should decide when key
+ * input ends. Use {@link layer} when Ctrl+C and Ctrl+D should end the key-input
+ * stream. For plain byte-oriented stdin/stdout access, use the `Stdio` service
+ * instead.
+ *
+ * **Gotchas**
+ *
+ * When stdin is a TTY, raw mode is enabled while the scoped terminal is active
+ * and restored on release. Raw mode changes how keys are delivered and can
  * affect other code reading stdin. In non-TTY environments such as pipes,
  * redirected input, or CI, raw mode is unavailable, keypress behavior is
  * limited, and stdout dimensions may be reported as zero.

package/src/index.ts

@@ -5,229 +5,61 @@
 // @barrel: Auto-generated exports. Do not edit manually.
 
 /**
- * Node.js implementation of `ChildProcessSpawner`.
- *
  * @since 4.0.0
  */
 export * as NodeChildProcessSpawner from "./NodeChildProcessSpawner.ts"
 
 /**
- * Node TCP socket integration for Effect Cluster runner communication.
- *
- * This module provides the shared Node layers used by socket-based cluster
- * transports: a client protocol that opens TCP sockets to runner addresses and
- * a socket server that listens for incoming runner RPC traffic. It is useful
- * when wiring Node or Node-compatible cluster runners, sharing the same socket
- * implementation across platform packages, or building tests and deployments
- * that need direct runner-to-runner RPC over TCP rather than HTTP.
- *
- * Cluster runners must advertise an address that peers can reach while the
- * server may listen on a different address via `runnerListenAddress`, which is
- * common behind containers, port mappings, or Kubernetes services. Serialization
- * is supplied by the surrounding layer, and gossip, shard discovery, health
- * checks, and storage-backed delivery are coordinated by the cluster services
- * that use this transport. Keep those responsibilities separate when debugging:
- * a reachable socket does not by itself guarantee that runner membership,
- * shard ownership, or persisted message notification is current.
- *
  * @since 4.0.0
  */
 export * as NodeClusterSocket from "./NodeClusterSocket.ts"
 
 /**
- * Node.js implementation of the Crypto service.
- *
  * @since 1.0.0
  */
 export * as NodeCrypto from "./NodeCrypto.ts"
 
 /**
- * Shared Node-compatible implementation of Effect's `FileSystem` service.
- *
- * This module adapts Node's `node:fs`, `node:os`, and `node:path` APIs into a
- * layer that can be provided to Effect programs running on Node-compatible
- * runtimes. It is used by platform packages to provide file and directory I/O,
- * permissions, links, metadata, temporary files and directories, and file
- * watching through the `FileSystem` service.
- *
- * Paths are passed to Node filesystem APIs, so relative paths are resolved by
- * the current working directory and platform path rules still apply. Node
- * filesystem failures are translated into `PlatformError` values, while invalid
- * arguments become `BadArgument` failures. Open files are scoped resources with
- * tracked read and write positions; append mode lets the operating system choose
- * the write offset. File watching is exposed as a stream and follows
- * `node:fs.watch` semantics unless a `WatchBackend` is provided, so recursive
- * support, event coalescing, and reported paths can vary by runtime and
- * platform.
- *
  * @since 4.0.0
  */
 export * as NodeFileSystem from "./NodeFileSystem.ts"
 
 /**
- * Shared Node-compatible implementation of Effect's `Path` service.
- *
- * This module adapts Node's `node:path` and `node:url` APIs into layers that
- * can be provided to Effect programs needing path manipulation, such as
- * resolving configuration files, building file system locations, parsing
- * names and extensions, or converting between file paths and `file:` URLs.
- *
- * The default layer follows the host platform semantics exposed by
- * `node:path`, while `layerPosix` and `layerWin32` provide stable POSIX or
- * Windows behavior regardless of the current runtime. Path operations are
- * syntactic and do not check whether files exist; separators, drive letters,
- * UNC paths, and URL encoding rules can also differ by platform. Invalid
- * file URL conversions are reported through `BadArgument`.
- *
  * @since 4.0.0
  */
 export * as NodePath from "./NodePath.ts"
 
 /**
- * Shared runtime helpers for running Effect programs as Node-compatible
- * process entry points.
- *
- * This module provides the common `runMain` implementation used by
- * Node-compatible platform packages. It is intended for CLIs, scripts,
- * workers, servers, and other process-oriented programs that should run an
- * Effect as their main fiber while still following Node process conventions.
- *
- * The runner installs `SIGINT` and `SIGTERM` handlers for the lifetime of the
- * main fiber, translating those process signals into fiber interruption so
- * Effect finalizers and the configured teardown can run. When the fiber exits,
- * the signal listeners are removed and teardown determines the exit code. Clean
- * success lets the Node event loop drain naturally instead of forcing
- * `process.exit(0)`, while signal-triggered or non-zero exits call
- * `process.exit` after teardown, so long-running resources should be modeled
- * in the Effect scope and finalized explicitly.
- *
  * @since 4.0.0
  */
 export * as NodeRuntime from "./NodeRuntime.ts"
 
 /**
- * Sink adapters for writing Effect stream chunks into Node writable streams.
- *
- * This module is used at the boundary where Effect `Stream`s or `Channel`s need
- * to push data into Node's writable side: file streams, HTTP request or
- * response bodies, process stdio, sockets, and transform inputs such as
- * compression or encryption streams. It exposes both a `Sink` constructor for
- * ordinary stream pipelines and lower-level `Channel` and pull helpers used by
- * other Node stream adapters.
- *
- * The implementation follows Node writable semantics. Chunks are written in
- * order; when `write` returns `false`, pulling pauses until `drain` so upstream
- * producers do not overrun the writable buffer. Writable `error` events are
- * mapped through `onError`, and the writable is ended and awaited via `finish`
- * when upstream completes unless `endOnDone` is `false`. Use `endOnDone: false`
- * for externally owned or long-lived writables, and make sure `onError` keeps
- * Node's untyped errors meaningful for the calling Effect workflow.
- *
  * @since 4.0.0
  */
 export * as NodeSink from "./NodeSink.ts"
 
 /**
- * Shared Node socket constructors for adapting `node:net` connections and
- * other Node `Duplex` streams to Effect's `Socket.Socket` interface.
- *
- * Use this module when building TCP clients, Unix domain socket clients, or
- * higher-level protocols that already expose a Node `Duplex`. Connections are
- * scoped, so finalizers close or destroy the underlying stream, open timeouts
- * are reported as socket open errors, and Node read, write, and close events
- * are translated into `SocketError` values.
- *
- * Node sockets have a few operational details worth keeping in mind: Unix
- * socket paths are supplied through `NetConnectOpts.path`, writes complete only
- * after Node accepts or flushes the chunk, and abnormal close events are
- * surfaced as close errors while normal remote ends complete the socket run.
- *
  * @since 4.0.0
  */
 export * as NodeSocket from "./NodeSocket.ts"
 
 /**
- * Shared Node socket server constructors for exposing `node:net` servers and
- * `ws` WebSocket servers as Effect `SocketServer.SocketServer` services.
- *
- * Use this module when implementing TCP services, Unix domain socket services,
- * WebSocket endpoints, or higher-level protocols such as RPC transports that
- * need to accept incoming connections through Effect's socket APIs. TCP
- * connections are adapted through `NodeSocket.fromDuplex`, while WebSocket
- * handlers also receive the underlying `WebSocket` and Node `IncomingMessage`
- * in their fiber context.
- *
- * The server starts listening before the constructor returns, and the exported
- * `address` is derived from the actual Node server after binding. Prefer that
- * address when using port `0`, wildcard hosts, or Unix socket paths. Incoming
- * connections accepted before `run` is installed are queued and then handed to
- * the handler, each `run` call owns the scope for its connection fibers, and
- * the enclosing scope closes the underlying Node server.
- *
  * @since 4.0.0
  */
 export * as NodeSocketServer from "./NodeSocketServer.ts"
 
 /**
- * Shared Node.js implementation of the Effect `Stdio` service.
- *
- * This module builds the `Stdio` layer used by Node platform packages by
- * wiring the service to the current process: command-line arguments come from
- * `process.argv`, input is read from `process.stdin`, and output and error
- * output are written to `process.stdout` and `process.stderr`. It is intended
- * for CLIs, scripts, command runners, test harnesses, and other
- * process-oriented programs that need standard I/O through Effect services.
- *
- * The process stdio streams are global resources owned by Node. This layer
- * leaves stdin open and does not end stdout or stderr by default, avoiding
- * accidental closure of handles other code in the process may still use. Those
- * streams may be pipes, files, or TTYs; interactive terminal behavior such as
- * raw mode, echo, colors, and cursor movement should be coordinated with the
- * terminal APIs instead of assuming this layer has exclusive control.
- *
  * @since 4.0.0
  */
 export * as NodeStdio from "./NodeStdio.ts"
 
 /**
- * Interoperability between Node streams and Effect streams and channels.
- *
- * This module adapts `Readable` and `Duplex` instances at the boundary with
- * Node APIs: wrapping sources such as files, HTTP responses, child process
- * output, and compression transforms as Effect `Stream`s or `Channel`s, piping
- * Effect streams through Node duplex transforms, exposing an Effect `Stream`
- * back to Node as a `Readable`, and collecting small readable payloads into
- * strings or binary buffers.
- *
- * The adapters preserve the Node stream semantics that matter for production
- * code. Writes wait for `drain` when a writable side applies backpressure,
- * readable streams are destroyed on scope finalization by default, and stream
- * failures are routed through `onError` or `Cause.UnknownError`. For long-lived
- * or externally owned streams, pass `closeOnDone` or `endOnDone` carefully, and
- * use `maxBytes` on collection helpers to avoid buffering unbounded input.
- *
  * @since 4.0.0
  */
 export * as NodeStream from "./NodeStream.ts"
 
 /**
- * Shared Node.js implementation of Effect's `Terminal` service.
- *
- * This module is the process-backed terminal implementation used by Node
- * platform packages. It adapts Node's `readline` APIs and the current
- * process' `stdin` and `stdout` streams into a `Terminal`, making it suitable
- * for CLIs, REPLs, prompts, full-screen terminal programs, and other
- * command-line tools that need line input, keypress input, terminal
- * dimensions, or prompt output.
- *
- * The implementation works with global process streams, so callers should
- * acquire it with a scope or provide `layer` to ensure cleanup. When `stdin`
- * is a TTY, raw mode is enabled while the scoped readline interface is active
- * and restored on release; raw mode changes how keys are delivered and can
- * affect other code reading stdin. In non-TTY environments such as pipes,
- * redirected input, or CI, raw mode is unavailable, keypress behavior is
- * limited, and stdout dimensions may be reported as zero.
- *
  * @since 4.0.0
  */
 export * as NodeTerminal from "./NodeTerminal.ts"