Chris Tate
524af28870
fs.createReadStream, fs.createWriteStream and FileHandle createReadStream, createWriteStream and readLines return runtime Readable and Writable streams (scr_fs_stream.c), as do new fs.ReadStream and new fs.WriteStream in JavaScript sources. They follow lib/internal/fs/streams.js on the stream engine: - _construct opens the file, then emits 'open' (with the fd) and 'ready'; _read reads up to end; _write retries short writes as writeAll does; _destroy waits for I/O in flight, then closes (with fsync first for the flush option). Every open, read, write, fsync and close runs on the shared worker pool. - Options are checked in Node's order: getOptions, options.fd or the path, start, end, then highWaterMark, encoding, emitClose and autoClose. flags and mode are checked when the file opens, so their errors arrive as 'error' events. - bytesRead, bytesWritten, pending, path and close(cb) compile, also through untyped values (close() there). A FileHandle stream holds a reference on the handle; closing the stream releases it and closes the handle unless autoClose is false. FileHandle.close() follows Node's reference count: it waits for the streams over the handle and runs their close(). readLines is a readline Interface over createReadStream with crlfDelay: Infinity. The stream engine gains Node's _construct (reads, buffered writes, finish and _destroy wait for construction; destroy errors combine with aggregateTwoErrors) and _writev, both internal. Writable.destroy() now runs the buffered write callbacks and end() callbacks (errorBuffer), which it dropped before. highWaterMark in a dynamic options record is checked as getHighWaterMark does, and for await over a constructing stream waits for construction. Numeric flags, the fs, signal and windowsHandle options, non-UTF-8 write encodings, option functions that replace the file implementation, and instanceof fs.ReadStream/WriteStream are refused. Corpus 5546, 5547 and 5554 cover both lanes against Node 24.22.
Node compatibility ledger
This workspace package owns scriptc's Node.js parity system.
node-v24.jsonpins the Node release tag, commit, and canonical docs/source inputs.static-support.jsonoverlays dedicated compiler paths and their internal test evidence on the compiler's generated surface manifest.generated/node-v24-internal.jsonis the engineering ledger, including implementation evidence and repository test paths.generated/node-v24-backlog.jsonis the internal tier-specific work queue. It separates verification, implementation, explicit-refusal replacement, and partial-surface audit work, and prioritizes stable Node APIs above experimental, deprecated, and legacy APIs.docs/src/generated/node-v24-compatibility.jsonis the stripped public artifact consumed by the docs website. It contains compiler-relevant runtime APIs, statuses, verification bases, and user-facing details; documentation, metadata, command-line/configuration entries, and rows that are N/A for native execution remain internal.
Statuses are evidence-aware: supported and partial require test evidence; refused requires an explicit compiler diagnostic or native throwing stub; not-implemented is the actionable backlog for an owned API family with no implementation match; by-design records an architectural exclusion; unreviewed still needs classification; and not-applicable is not a runtime API for that execution tier.
Run pnpm node-compat:backlog from the repository root for a summary. The filters --tier, --action, --priority, --chapter, and --status compose; use --format=json or --format=tsv for tooling.
Run pnpm node-compat from the repository root after changing the Node pin or the support manifest. pnpm node-compat:check is the offline drift/evidence gate; pnpm --filter @internal/compatibility check:upstream additionally verifies the pinned upstream inputs over the network.