Readiness: Implemented

Reference

@uniflowed/std

// @flow
import { as, is, wrap } from "@uniflowed/std/errors";
import { Group } from "@uniflowed/std/sync";
import { withTimeout, background } from "@uniflowed/std/context";

const [ctx, cancel] = withTimeout(background(), 5_000);
try {
  const group = new Group({ limit: 8 });
  for (const id of ids) group.go((signal) => fetchRow(id, signal));
  return await group.wait();
} catch (failure) {
  if (is(failure, ctx.err())) return cached;
  throw wrap("loading the dashboard", failure);
} finally {
  cancel();
}

What ships today

Twenty modules. Each is a separate subpath, so importing @uniflowed/std/hex brings in a hex codec and nothing else.

The root @uniflowed/std is unchanged: it is a declaration surface whose functions raise NativeRuntimeRequiredError, and it is not what these twenty are. Everything above runs.

The types are the point

Every generic here infers at the call site, with no annotation and no any underneath, and that claim is tested rather than asserted: tests/type-tests/std-inference.js is a file of deliberate misuses, and uf check has to report every one of them and nothing else.

const queue = new Heap((a, b) => a.due - b.due);   // Heap<Job>, from the comparator
const next = queue.pop();                          // Job | void

const TRACE = key<string>("trace-id");
withValue(ctx, TRACE, 7);                          // refused: 7 is not a string
traced.value(TRACE);                               // string | void

as(failure, HttpError)?.status;                    // number, from the class alone

Cancellation: why not just AbortSignal

Every context has one — ctx.signal() is what goes to fetch — so this composes with the platform rather than competing with it. What it adds is the three things AbortSignal does not have: a tree, so cancelling a request cancels everything it started; deadlines that only ever shorten, so a library cannot buy itself more time than its caller allowed; and typed request-scoped values.

AbortSignal.any and AbortSignal.timeout cover parts of the first two, and they are the newest things on the interface — Node, Deno, Bun and workerd gained them at different times. Nothing here uses either.

One thing it asks of you that Go does not. A deadline is a setTimeout, and on Node a pending timer keeps the process alive. There is no runtime-agnostic unref — Deno and browsers have none — so the cancel that withTimeout hands back has to be called, in a finally, on the happy path too.

Where it runs

Everything here is pure Flow over the web platform: Uint8Array, TextEncoder/TextDecoder, AbortController, Promise, setTimeout. No node: import, no native binding, no Buffer.

The bottom two rows say "expected" rather than "yes" on purpose, and the distinction is the one docs/hosts.md exists to make: a row nothing has started the runtime for is a claim, not a result. What the claim rests on is that nothing here imports node: anything, touches Buffer, or reads process, and that AggregateError — the newest platform feature any of it needs, returned by errors.join — has been in all four runtimes since 2020. That is a good reason to expect it to work and it is not a test.

Why this is JavaScript and not Rust

uf is a native toolchain, so "should this be native" is a fair question for every module. It was measured rather than guessed, and the answer for these modules is no.

The comparison is against Node's own C++ implementations of the same operations — Buffer#toString("hex"), Buffer#equals, Buffer#indexOf — reached across the same kind of JavaScript-to-native boundary a binding would use. That makes it a measurement of what native buys, not an estimate of it. Node 24 on an M-series laptop, nanoseconds per call:

Three things follow from that table, and only the third is about speed.

The boundary is not free, and below a few dozen bytes it is the whole bill. bytes.equal on sixteen bytes is faster in JavaScript than the native call that does the same thing, because comparing sixteen bytes takes less time than crossing into C++ to do it. Most calls to most of these functions are small: a 32-byte digest, a four-byte delimiter, a header value.

There is no binding to cross anyway. There is no N-API and no WebAssembly crate anywhere in this repository. "Native" for a @uniflowed/std module is not a build flag; it is a layer that does not exist yet, and the first module to need one should be the module that pays for it.

A native module would not be runtime-agnostic. An N-API addon runs on Node and Bun and not on Deno or the edge, which is red line 6. A WebAssembly module runs everywhere and copies its arguments across the boundary — which, for a function whose argument is a byte buffer, is the cost the native implementation was supposed to save.

So the effort went where it was measurable instead. Each of these is one implementation of the same function against another, both in JavaScript:

The last two are not micro-optimisations. They are the difference between linear and quadratic, which is the difference between a service that is fine in staging and one that falls over in production.

Go's standard library, mapped

Every part of it lands in one of three places, and the point of writing the whole map down is that the second bucket is the only one that is work. Most of Go's standard library is either already in JavaScript or cannot be in a runtime-agnostic module at all, and a survey that only listed the gaps would read like a to-do list nobody would ever finish.

Already in JavaScript — do not reimplement

A port of these would be slower, less correct, and a second name for something that already has one.

errors and context belong here partly, and that is exactly why they were first: Error.cause and AbortSignal are the platform's answers, and neither has a reader for a chain or a tree of scopes. The two modules that shipped build on them rather than replacing them.

Missing, and worth having

The first six at the top of this page are tranche 1. slices, base32, list, csv, binary, path, glob, hash, time, io, bufio, textproto, zip and tar are the first next-tranche pieces. What remains is still useful, but no next-tranche module is left waiting on this page.

sync.RWMutex is deliberately absent rather than pending: readers and writers cannot run at the same time in one runtime, so it would buy a fairness policy and nothing else, and it should arrive with the workload that needs one.

Not this package's to write

Each of these fails the same test — a module in @uniflowed/std has to work on Node, Bun, Deno and the edge runtimes, or say exactly where it does not.

Where the map lives, so it cannot drift

Not here. This page is the readable half; the checked half is crates/uf_std/src/registry.rs, where every @uniflowed/std/* specifier carries a status — ships, declared, planned or declined — and uf inspect --json emits it under stdModules.

That field exists because the table did not have one, and a table without one is read as an inventory however it was written. It named forty-five specifiers, forty-four of which had no file, every one of them constructed by a function that hardcoded nativeBinding: true and wintertcAligned: true — so it could not describe a shipped pure-JavaScript module without lying about it, and it described @uniflowed/std/net as WinterTC-aligned while TcpListener was in its export list. Four tests now hold the statuses to npm/std: the shipping specifiers are exactly the manifest's subpaths, each one's export list is exactly what the parser finds in its file, a shipping module never raises NativeRuntimeRequiredError and the root always does, and nothing claiming WinterTC alignment imports node: anything or reads Buffer or process.

uf inspect prints the ships count and the rest as a roadmap beside it, for the same reason @uniflowed/ui does. A count with a wish in it is worse than no count.

Edit this pagedocs/app/reference/std/$page.mdx