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

package/dist/index.d.ts

@@ -2,218 +2,50 @@
  * @since 4.0.0
  */
 /**
- * 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";

package/dist/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA;;GAEG;AAIH;;;;GAIG;AACH,OAAO,KAAK,uBAAuB,MAAM,8BAA8B,CAAA;AAEvE;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,OAAO,KAAK,iBAAiB,MAAM,wBAAwB,CAAA;AAE3D;;;;GAIG;AACH,OAAO,KAAK,UAAU,MAAM,iBAAiB,CAAA;AAE7C;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,OAAO,KAAK,cAAc,MAAM,qBAAqB,CAAA;AAErD;;;;;;;;;;;;;;;;GAgBG;AACH,OAAO,KAAK,QAAQ,MAAM,eAAe,CAAA;AAEzC;;;;;;;;;;;;;;;;;;;GAmBG;AACH,OAAO,KAAK,WAAW,MAAM,kBAAkB,CAAA;AAE/C;;;;;;;;;;;;;;;;;;;GAmBG;AACH,OAAO,KAAK,QAAQ,MAAM,eAAe,CAAA;AAEzC;;;;;;;;;;;;;;;;GAgBG;AACH,OAAO,KAAK,UAAU,MAAM,iBAAiB,CAAA;AAE7C;;;;;;;;;;;;;;;;;;;GAmBG;AACH,OAAO,KAAK,gBAAgB,MAAM,uBAAuB,CAAA;AAEzD;;;;;;;;;;;;;;;;;;GAkBG;AACH,OAAO,KAAK,SAAS,MAAM,gBAAgB,CAAA;AAE3C;;;;;;;;;;;;;;;;;;GAkBG;AACH,OAAO,KAAK,UAAU,MAAM,iBAAiB,CAAA;AAE7C;;;;;;;;;;;;;;;;;;;GAmBG;AACH,OAAO,KAAK,YAAY,MAAM,mBAAmB,CAAA"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA;;GAEG;AAIH;;GAEG;AACH,OAAO,KAAK,uBAAuB,MAAM,8BAA8B,CAAA;AAEvE;;GAEG;AACH,OAAO,KAAK,iBAAiB,MAAM,wBAAwB,CAAA;AAE3D;;GAEG;AACH,OAAO,KAAK,UAAU,MAAM,iBAAiB,CAAA;AAE7C;;GAEG;AACH,OAAO,KAAK,cAAc,MAAM,qBAAqB,CAAA;AAErD;;GAEG;AACH,OAAO,KAAK,QAAQ,MAAM,eAAe,CAAA;AAEzC;;GAEG;AACH,OAAO,KAAK,WAAW,MAAM,kBAAkB,CAAA;AAE/C;;GAEG;AACH,OAAO,KAAK,QAAQ,MAAM,eAAe,CAAA;AAEzC;;GAEG;AACH,OAAO,KAAK,UAAU,MAAM,iBAAiB,CAAA;AAE7C;;GAEG;AACH,OAAO,KAAK,gBAAgB,MAAM,uBAAuB,CAAA;AAEzD;;GAEG;AACH,OAAO,KAAK,SAAS,MAAM,gBAAgB,CAAA;AAE3C;;GAEG;AACH,OAAO,KAAK,UAAU,MAAM,iBAAiB,CAAA;AAE7C;;GAEG;AACH,OAAO,KAAK,YAAY,MAAM,mBAAmB,CAAA"}

package/dist/index.js

@@ -3,218 +3,50 @@
  */
 // @barrel: Auto-generated exports. Do not edit manually.
 /**
- * Node.js implementation of `ChildProcessSpawner`.
- *
  * @since 4.0.0
  */
 export * as NodeChildProcessSpawner from "./NodeChildProcessSpawner.js";
 /**
- * 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.js";
 /**
- * Node.js implementation of the Crypto service.
- *
  * @since 1.0.0
  */
 export * as NodeCrypto from "./NodeCrypto.js";
 /**
- * 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.js";
 /**
- * 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.js";
 /**
- * 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.js";
 /**
- * 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.js";
 /**
- * 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.js";
 /**
- * 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.js";
 /**
- * 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.js";
 /**
- * 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.js";
 /**
- * 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.js";

package/dist/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","names":["NodeChildProcessSpawner","NodeClusterSocket","NodeCrypto","NodeFileSystem","NodePath","NodeRuntime","NodeSink","NodeSocket","NodeSocketServer","NodeStdio","NodeStream","NodeTerminal"],"sources":["../src/index.ts"],"sourcesContent":[null],"mappings":"AAAA;;;AAIA;AAEA;;;;;AAKA,OAAO,KAAKA,uBAAuB,MAAM,8BAA8B;AAEvE;;;;;;;;;;;;;;;;;;;;;AAqBA,OAAO,KAAKC,iBAAiB,MAAM,wBAAwB;AAE3D;;;;;AAKA,OAAO,KAAKC,UAAU,MAAM,iBAAiB;AAE7C;;;;;;;;;;;;;;;;;;;;;AAqBA,OAAO,KAAKC,cAAc,MAAM,qBAAqB;AAErD;;;;;;;;;;;;;;;;;AAiBA,OAAO,KAAKC,QAAQ,MAAM,eAAe;AAEzC;;;;;;;;;;;;;;;;;;;;AAoBA,OAAO,KAAKC,WAAW,MAAM,kBAAkB;AAE/C;;;;;;;;;;;;;;;;;;;;AAoBA,OAAO,KAAKC,QAAQ,MAAM,eAAe;AAEzC;;;;;;;;;;;;;;;;;AAiBA,OAAO,KAAKC,UAAU,MAAM,iBAAiB;AAE7C;;;;;;;;;;;;;;;;;;;;AAoBA,OAAO,KAAKC,gBAAgB,MAAM,uBAAuB;AAEzD;;;;;;;;;;;;;;;;;;;AAmBA,OAAO,KAAKC,SAAS,MAAM,gBAAgB;AAE3C;;;;;;;;;;;;;;;;;;;AAmBA,OAAO,KAAKC,UAAU,MAAM,iBAAiB;AAE7C;;;;;;;;;;;;;;;;;;;;AAoBA,OAAO,KAAKC,YAAY,MAAM,mBAAmB","ignoreList":[]}
+{"version":3,"file":"index.js","names":["NodeChildProcessSpawner","NodeClusterSocket","NodeCrypto","NodeFileSystem","NodePath","NodeRuntime","NodeSink","NodeSocket","NodeSocketServer","NodeStdio","NodeStream","NodeTerminal"],"sources":["../src/index.ts"],"sourcesContent":[null],"mappings":"AAAA;;;AAIA;AAEA;;;AAGA,OAAO,KAAKA,uBAAuB,MAAM,8BAA8B;AAEvE;;;AAGA,OAAO,KAAKC,iBAAiB,MAAM,wBAAwB;AAE3D;;;AAGA,OAAO,KAAKC,UAAU,MAAM,iBAAiB;AAE7C;;;AAGA,OAAO,KAAKC,cAAc,MAAM,qBAAqB;AAErD;;;AAGA,OAAO,KAAKC,QAAQ,MAAM,eAAe;AAEzC;;;AAGA,OAAO,KAAKC,WAAW,MAAM,kBAAkB;AAE/C;;;AAGA,OAAO,KAAKC,QAAQ,MAAM,eAAe;AAEzC;;;AAGA,OAAO,KAAKC,UAAU,MAAM,iBAAiB;AAE7C;;;AAGA,OAAO,KAAKC,gBAAgB,MAAM,uBAAuB;AAEzD;;;AAGA,OAAO,KAAKC,SAAS,MAAM,gBAAgB;AAE3C;;;AAGA,OAAO,KAAKC,UAAU,MAAM,iBAAiB;AAE7C;;;AAGA,OAAO,KAAKC,YAAY,MAAM,mBAAmB","ignoreList":[]}

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@effect/platform-node-shared",
   "type": "module",
-  "version": "4.0.0-beta.70",
+  "version": "4.0.0-beta.72",
   "license": "MIT",
   "description": "Unified interfaces for common platform-specific services",
   "homepage": "https://effect.website",
@@ -46,12 +46,12 @@
     "provenance": true
   },
   "peerDependencies": {
-    "effect": "^4.0.0-beta.70"
+    "effect": "^4.0.0-beta.72"
   },
   "devDependencies": {
     "@types/node": "^25.7.0",
     "tar": "^7.5.15",
-    "effect": "^4.0.0-beta.70"
+    "effect": "^4.0.0-beta.72"
   },
   "dependencies": {
     "@types/ws": "^8.18.1",

package/src/NodeChildProcessSpawner.ts

@@ -1,5 +1,19 @@
 /**
- * Node.js implementation of `ChildProcessSpawner`.
+ * Shared Node.js implementation of the child process spawner service.
+ *
+ * This module adapts `node:child_process.spawn` to the Effect
+ * `ChildProcessSpawner` service. Provide {@link layer} to run `ChildProcess`
+ * commands in Node-compatible runtimes: commands get scoped process handles
+ * with stdin sinks, stdout and stderr streams, exit-code waiting,
+ * interruption-time cleanup, process killing, and custom file-descriptor pipes.
+ *
+ * The implementation sits below the command-building API. It validates and
+ * resolves `cwd` through the Effect `FileSystem` and `Path` services,
+ * translates Node errno failures to `PlatformError`, and uses scopes to
+ * terminate referenced children when the owning effect is interrupted or
+ * finalized. Pipelines are flattened by {@link flattenCommand} and spawned one
+ * process at a time, wiring the selected source stream (`stdout`, `stderr`,
+ * `all`, or `fdN`) to the destination `stdin` or `fdN`.
  *
  * @since 4.0.0
  */
@@ -625,7 +639,7 @@ const make = Effect.gen(function*() {
 })
 
 /**
- * Layer providing the `NodeChildProcessSpawner` implementation.
+ * Layer that provides the `NodeChildProcessSpawner` implementation.
  *
  * @category layers
  * @since 4.0.0

package/src/NodeClusterSocket.ts

@@ -1,21 +1,34 @@
 /**
- * Node TCP socket integration for Effect Cluster runner communication.
+ * Node TCP socket transport for Effect Cluster runner-to-runner RPC.
  *
  * 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.
+ * transports. `layerClientProtocol` opens TCP sockets to peer runner addresses
+ * and wraps them in the current RPC serialization protocol. `layerSocketServer`
+ * exposes the socket server that receives incoming runner RPC traffic.
  *
- * 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.
+ * **Mental model**
+ *
+ * The cluster runtime decides which runners exist, which shards they own, and
+ * which messages must be delivered. This module only provides the TCP transport
+ * those services use after a runner address has been selected. The client side
+ * dials an advertised runner address; the server side listens on the address
+ * configured for the local runner.
+ *
+ * **Common tasks**
+ *
+ * Add these layers when a Node or Node-compatible cluster deployment should use
+ * direct socket RPC instead of an HTTP transport. Configure `runnerAddress` as
+ * the address other runners can reach, and configure `runnerListenAddress` when
+ * the local process must bind a different host or port.
+ *
+ * **Gotchas**
+ *
+ * Containers, port mappings, and Kubernetes services often require different
+ * advertised and listening addresses. Serialization is provided by the
+ * surrounding layer, not by this module. A reachable socket confirms only that
+ * TCP transport is available; gossip, shard ownership, health checks, and
+ * persisted message notification are coordinated by the cluster services that
+ * use this transport.
  *
  * @since 4.0.0
  */

package/src/NodeCrypto.ts

@@ -1,5 +1,25 @@
 /**
- * Node.js implementation of the Crypto service.
+ * The `NodeCrypto` module implements Effect's `Crypto` service with
+ * Node-compatible `node:crypto` APIs. It exports {@link make} as the concrete
+ * service value and {@link layer} for providing that service to programs that
+ * need cryptographic random bytes, UUID generation, random values, or SHA
+ * digests over `Uint8Array` input.
+ *
+ * **Common tasks**
+ *
+ * - Provide {@link layer} in Node-compatible platform packages and tests
+ * - Reuse {@link make} when a surrounding layer already manages service
+ *   construction
+ * - Compute SHA-1, SHA-256, SHA-384, or SHA-512 digests through
+ *   `effect/Crypto` after the layer is provided
+ *
+ * **Gotchas**
+ *
+ * - Random bytes come from `node:crypto.randomBytes`
+ * - Digests use `node:crypto.createHash`; hash failures become platform
+ *   errors
+ * - SHA-1 is included for interoperability with existing protocols, not for
+ *   new security-sensitive designs
  *
  * @since 1.0.0
  */
@@ -47,7 +67,7 @@ export const make: EffectCrypto.Crypto = EffectCrypto.make({
 })
 
 /**
- * A layer that provides the Node.js Crypto service implementation.
+ * Layer that provides the Node.js Crypto service implementation.
  *
  * @category layers
  * @since 1.0.0

package/src/NodeFileSystem.ts

@@ -2,19 +2,32 @@
  * 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.
+ * `FileSystem` layer for Effect programs running on Node-compatible runtimes.
+ * Platform packages use it to provide file and directory I/O, permissions,
+ * links, metadata, temporary files and directories, and file watching through
+ * the shared `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
+ * **Mental model**
+ *
+ * {@link layer} installs a process-backed `FileSystem` service. Each operation
+ * delegates to the corresponding Node filesystem API, then maps Node failures
+ * into `PlatformError` values and invalid arguments into `BadArgument` failures.
+ * Paths keep Node's normal behavior: relative paths resolve from the current
+ * working directory and platform path rules still apply.
+ *
+ * **Common tasks**
+ *
+ * Provide {@link layer} at the Node runtime boundary, then depend on the
+ * `FileSystem` service from application code. Use the service for ordinary
+ * reads and writes, directory management, metadata inspection, links, temporary
+ * resources, and file watching without importing Node's `fs` APIs directly.
+ *
+ * **Gotchas**
+ *
+ * Open files are scoped resources with tracked read and write positions; append
+ * mode lets the operating system choose the write offset. File watching follows
+ * `node:fs.watch` semantics unless a custom watch backend is supplied, so
+ * recursive support, event coalescing, and reported paths vary by runtime and
  * platform.
  *
  * @since 4.0.0