A dozen or so Rust crates — mostly libraries, plus the gen-compile-cache binary — linked into workerd via CXX FFI. No Cargo workspace — entirely Bazel-driven (wdrustcrate.bzl / wdrustbinary.bzl). Clippy pedantic+nursery enabled; allow-unwrap-in-tests; clippy.toml and rustfmt.toml live at the repository root and apply to every crate. Rust does not have to live here. A crate that belongs to a component lives beside that component's C++, in the same package, in a subdirectory named for the crate: e.g. workerd's entry point…
This directory contains workerd's in-tree fork of cxx-rs. It was imported from the former cloudflare/workerd-cxx repository. Changes to the fork and its workerd consumers should use the in-tree Bazel labels and land atomically. The fork adds KJ exceptions, smart pointers, data types, and bidirectional async interop. Do not assume stock cxx-rs behavior when changing bridge generation or runtime code. Run commands from the workerd repository root: Important targets: Dependencies come from workerd's @crates_vendor repository and @capnp-cpp; do not add a…
Test suites for the parts of the Node.js compatibility layer (src/node/) that sit on top of the Web Streams implementation: the node:stream web-interop adapters, node:net sockets over connect() stream halves, and the node:http client and server over fetch() bodies. One subdirectory per area. Every test here runs against both streams implementations — the legacy C++ one (src/workerd/api/streams/) and the TypeScript one (src/per_isolate/webstreams/) — to prove the node layer behaves identically on either. The suite rules are those of src/tests/streams/AGENTS.md, applied…
An informal specification of how a node:http ClientRequest drives fetch() and the web streams underneath it — the request body it gathers and hands to fetch(), and the Response body it pumps into its IncomingMessage — derived from and kept in lockstep with the test suite in this directory. The tests are the normative artifact; this document maps behaviors to the tests that assert them. Every test runs against the C++ streams implementation (http-client-cpp.wd-test) and the TypeScript one (http-client-ts.wd-test). The…
An informal specification of how a node:http Server drives the web streams underneath it — the Request body it pumps into the IncomingMessage, and the ReadableStream the ServerResponse builds as the body of the Response it hands back to fetch() — derived from and kept in lockstep with the test suite in this directory. The tests are the normative artifact; this document maps behaviors to the tests that assert them. Every test runs against the C++ streams implementation (http-server-cpp.wd-test) and…
An informal specification of how a node:net Socket drives the two web-stream halves of the connect() socket underneath it, derived from and kept in lockstep with the test suite in this directory. The tests are the normative artifact; this document maps behaviors to the tests that assert them. Every test runs against the C++ streams implementation (net-cpp.wd-test) and the TypeScript one (net-ts.wd-test). The general net surface (option validation, DNS, BlockList, SocketAddress, BoundSocket, abort signals, reconnect) is owned by src/workerd/api/node/tests/net-nodejs-test.js; this…
An informal specification of the node:stream web-interop surface — Readable.toWeb/fromWeb, Writable.toWeb/fromWeb, Duplex.toWeb/fromWeb, Duplex.from, Readable.from over a web stream, pipeline, compose, finished, addAbortSignal, node:stream/web, node:stream/consumers — derived from and kept in lockstep with the test suite in this directory. The tests are the normative artifact; this document maps behaviors to the tests that assert them. Every test runs against the C++ streams implementation (stream-cpp.wd-test) and the TypeScript one (stream-ts.wd-test); the divergence ledger pins the places where the node layer observes a…
Streams test suite, organized WPT-style: one subdirectory per functional area (identity/, encoding/, compression/, digest/, strategies/, readable/, readable-byte/, writable/, transform/, piping/, inspect/, r2-patterns/, iocontext/, cache/, htmlrewriter/, formdata/, sockets/, scaling/). Every test here runs against both streams implementations — the legacy C++ one (src/workerd/api/streams/) and the TypeScript one (src/per_isolate/webstreams/) — to prove parity. A test that only makes sense for one implementation's internals belongs elsewhere. - One file, one behavior. Decompose aggressively; the filename names the behavior. Shared setup helpers go in…
The Cache API consuming and producing stream bodies under both stream implementations. The tests are the normative artifact. The general Cache API surface (headers, vary, purge, instrumentation) is owned by src/workerd/api/tests/cache-*; this suite owns the STREAMS interaction only. All cells wire cacheApiOutbound to a loopback cache-backend worker (cache-backend.js). A cache.put() arrives there as a PUT whose body is the SERIALIZED HTTP RESPONSE (status line + headers + CRLFCRLF + body); the backend splits at the header boundary, verifies the continuous…
An informal specification of the two Compression Streams classes as implemented in workerd, derived from — and kept in lockstep with — the test suite in this directory. The tests are the normative artifact. Both the C++ implementation (src/workerd/api/streams/compression.{h,c++}, built on internal streams over the shared api/compression.h CodecStage) and the TypeScript implementation (src/perisolate/webstreams/compression.ts, behind typescriptimplemented_streams) are covered. The two wrap the SAME C++ zlib codec (the TS pair drives utils.newCompressionCodec handles), so codec output is parity by construction; divergences live…
An informal specification of the Cloudflare-specific DigestStream (a WritableStream subclass computing a hash digest) as implemented in workerd, derived from — and kept in lockstep with — the test suite in this directory. The tests are the normative artifact. Both the C++ implementation (src/workerd/api/crypto/crypto.{h,c++}) and the TypeScript implementation (src/perisolate/crypto/digest-stream.ts, behind typescriptimplemented_streams) are covered. Both drive the SAME native digest context (utils.createDigestContext → CRC/OpenSSL contexts and the WTF-8/toWellFormed string encoder), so hashing, string encoding, and byte counting are parity by construction;…
An informal specification of the two WHATWG Encoding stream classes as implemented in workerd, derived from — and kept in lockstep with — the test suite in this directory. The tests are the normative artifact; this document indexes every specified behavior to the test that asserts it. Both the C++ implementation (src/workerd/api/streams/encoding.{h,c++}) and the TypeScript implementation (src/perisolate/webstreams/encoding.ts, behind typescriptimplemented_streams) are covered. The WPT encoding/streams/* tests already run against both implementations (//src/wpt:encoding and //src/wpt:encoding-ts), so this suite complements WPT rather than…
Multipart parsing FROM streamed bodies and FormData serialized INTO a stream body — under both stream implementations. The tests are the normative artifact. The general FormData surface (W3C API matrix, urlencoded, entry semantics) is owned by src/workerd/api/tests/ form-data-test.js; this suite owns the STREAMS interaction only. Both cells set formdataparsersupports_files so multipart file entries parse as File objects.
HTMLRewriter consuming stream bodies, producing a stream body, and reading streamed replacement content — under both stream implementations. The tests are the normative artifact. The general rewriter surface (selectors, handler types, comments/doctype/text tokens, async handlers) is owned by src/workerd/api/tests/ htmlrewriter-test.js; this suite owns the STREAMS interaction only. Unlike the api/tests rewriter files (which pin the pre-fixup behavior via original-transform-stream-backpressure), the cpp cell here runs under the MODERN fixup-transform-stream-backpressure. After the next source chunk wakes a canceled rewriter pump, C++ makes…
An informal specification of the two workerd-specific identity stream surfaces, derived from — and kept in lockstep with — the test suite in this directory. The tests are the normative artifact; this document is the index that maps every specified behavior to the test that asserts it. Both the legacy C++ implementation (src/workerd/api/streams/) and the TypeScript implementation (src/perisolate/webstreams/identity.ts, behind typescriptimplemented_streams) are covered; where they deliberately diverge, both sides are specified and pinned. Unless marked otherwise, behaviors below describe the current…
Informal specification of node:util inspect output for every stream surface, derived from — and kept in lockstep with — this suite. The tests are the normative artifact. The C++ implementation installs a custom inspect exposing lock/state internals; the TypeScript implementation has none — every stream inspects as a bare ClassName {} regardless of state, so introspection consumers lose [state], [supportsBYOB], [length], and [expectsBytes] under TS. Both sides are pinned verbatim at every lifecycle transition. The C++ cell pins, beyond the…
Module evaluation runs OUTSIDE any IoContext, and streams constructed there must work — including when later used inside requests. Migrated wholesale from streams-iocontext-test.js (itself ported from the edgeworker streams-iocontext.ew-test), plus the module-scope WritableStream pin from streams-test.js and new byte-stream and TransformStream coverage. The tests are the normative artifact. Structure note: the module-scope streams live in global-scope-streams.js together with the routing fetch handler; main.js re-exports both. Moving the constructions would change which module's evaluation performs them. Cross-request state (tests 6-8) uses…
Informal specification of stream piping as implemented in workerd, derived from — and kept in lockstep with — this suite. The tests are the normative artifact. Endpoint behaviors belong to the sibling suites (writable/, transform/, readable/, readable-byte/); identity↔ identity piping — including the circular pipeThrough pin — lives in the identity suite's pipe-integration.js. The suite COMPLEMENTS WPT (//src/wpt:streams). The C++ seeds in piping/error-propagation-forward largely root-cause to harness shapes plus ledger #5/#6 below; piping/close-propagation-backward and error-propagation-backward are DISABLED for hangs —…
R2's SDK consumes workerd streams through readAtLeast-driven BYOB loops, tees, Request clones, and TextDecoderStream. This suite pins those real-world shapes against both implementations, migrated wholesale from streams-r2-patterns-test.js. The tests are the normative artifact. The readAtLeast tail rows all follow the C++ tail contract: a close below the minimum folds the available bytes into a done=false result and a follow-up read resolves done. The remaining divergences are the tee byobRequest model (row 2, accepted) and how much an identity-stream readAtLeast takes…
Informal specification of the value-oriented ReadableStream as implemented in workerd, derived from — and kept in lockstep with — this suite. The tests are the normative artifact. Byte streams (type:'bytes', BYOB) belong to the readable-byte suite; the pipeTo/ pipeThrough matrix belongs to piping/. The suite COMPLEMENTS WPT (//src/wpt:streams). Probing the C++ expectedFailures showed many root-cause to a handful of construction divergences (hwm Infinity rejection, validation order) rather than behavioral gaps; the reentrancy family is mostly parity at finite hwm.
Plain text files in a repository that tell a coding agent how the project works: commands to run, conventions to follow and things to avoid. CLAUDE.md, AGENTS.md, cursor rules and skills are the common kinds.
CLAUDE.md or AGENTS.md?
CLAUDE.md is read by Claude Code. AGENTS.md is an open format that Codex, Cursor and other agents read. Many projects keep one and point the other at it.
What is a skill?
A folder with a SKILL.md that describes one capability, such as filling PDFs or reviewing code. The agent loads it only when the task calls for it.
Can I search my own team's files too?
Your agents already can, over MCP, limited to the files you're allowed to read. Searching them from this page is coming.
CloudflareAGENTS.md