🌍 Environment Support

Our library is designed to be runtime agnostic: utilities target standard JavaScript capabilities instead of branching on named platforms.

📊 Compatibility Model

If a runtime provides the JavaScript and Web Platform APIs a utility needs, that utility can run there. This keeps @opentf/std portable across Node.js, Bun, Deno, browsers, edge workers, embedded engines such as QuickJS, and future runtimes without adding platform-specific detection helpers.


🛠️ Standard Web APIs

Most utilities are pure JavaScript. The few that need platform APIs use standard, cross-runtime Web APIs — never runtime-specific modules:

  • Crypto helpers (random, UUID, hash, HMAC) use the Web Crypto API via globalThis.crypto.

  • They throw a clear error if globalThis.crypto is unavailable.

globalThis.crypto is available out of the box in every runtime @opentf/std targets — Node.js ≥ 20, Bun, Deno, modern browsers, and edge workers — so no polyfill or runtime branching is required.

Info

@opentf/std does not expose public runtime detection helpers. Prefer checking for the capability your code needs, not the runtime name.


🚀 Future-Proof Design

The @opentf/std library is built using modern ESM standards and leverages native platform APIs wherever possible. By choosing this library, you are ensuring that your code:

  • Runs Anywhere Capabilities Exist: Seamlessly move logic between edge, server, browser, and embedded runtimes.

  • Remains Lightweight: Zero external dependencies and full tree-shaking support.

  • Stays Modern: We build on the latest JavaScript features and stable, standard platform APIs.

Last updated on
Edit this page