import { Readable, Writable } from 'node:stream';
import type { BufferedSinkWriter, XlsxSink } from './sink';
import type { XlsxSource } from './source';
/**
 * Wrap a filesystem path as an XlsxSource. `toBytes` reads the whole file into
 * memory; `toStream` opens a `fs.createReadStream` and bridges it to a Web
 * {@link ReadableStream} via `Readable.toWeb` so the ZIP reader can iterate
 * without loading the entire xlsx up front.
 */
export declare function fromFile(path: string): XlsxSource;
/**
 * Synchronous variant of {@link fromFile}. Convenience for tooling / scripts
 * where the cost of `await fs.readFile` outweighs the ergonomic gain. The
 * returned source's `toBytes` resolves immediately with the bytes already in
 * memory.
 */
export declare function fromFileSync(path: string): XlsxSource;
/**
 * Filesystem sink. Each `write(chunk)` call streams the bytes to disk via
 * `fs.createWriteStream`, honouring backpressure: the actual `writable.write`
 * for each chunk is queued behind any pending `drain`, so the writable's
 * internal buffer never grows past its `highWaterMark` (default 16 KB) no
 * matter how fast the producer hands chunks over.
 *
 * Note on the producer-side memory budget: the sink contract is
 * intentionally synchronous (`write(chunk): void`), so a producer that races
 * ahead without yielding will let chunk references pile up in the queue.
 * That keeps `writable`'s buffer bounded but does not bound the queue
 * itself. Producers that need a hard ceiling should yield between writes
 * (`await new Promise(setImmediate)` is enough) or use a sink with an async
 * write contract.
 *
 * `result()` returns the destination path; `finish()` resolves with an empty
 * `Uint8Array` once the stream has flushed. Callers that need the on-disk
 * bytes should `readFile()` the returned path themselves — re-reading inside
 * `finish()` would defeat the "streamed to disk, never resident" guarantee.
 */
export declare function toFile(path: string): XlsxSink & {
    toBytes(): BufferedSinkWriter;
    result(): string;
};
/**
 * Wrap a Node.js {@link Readable} as an XlsxSource. `toBytes` consumes the
 * entire stream synchronously (collecting chunks); `toStream` bridges to a Web
 * ReadableStream via `Readable.toWeb` so the ZIP reader can pull chunks lazily.
 */
export declare function fromReadable(readable: Readable): XlsxSource;
/**
 * Wrap a Node.js {@link Writable} as an XlsxSink. The actual
 * `writable.write` for each chunk is queued behind any pending `drain`, so
 * the writable's internal buffer never exceeds its `highWaterMark` regardless
 * of how fast the producer is. See {@link toFile} for the same caveat about
 * producer-side memory: the synchronous `write(chunk)` API does not let
 * backpressure flow back to the caller, so a tight non-yielding producer can
 * still let chunk references accumulate in the queue.
 *
 * `result()` returns the writable itself for downstream chaining.
 */
export declare function toWritable(writable: Writable): XlsxSink & {
    toBytes(): BufferedSinkWriter;
    result(): Writable;
};