I’m excited to share @bluehive/random, a TypeScript-first, fully unit-tested, 100% API-compatible port of Meteor’s random package, now available as a modern npm package! GitHub Repo | Live Demos & Docs
Why Another Random Port?
There are a few Meteor random ports, but I needed a solution that checks these boxes:
Full TypeScript support (with complete type definitions)
Comprehensive unit tests (89%+ coverage, 79 tests, see coverage reports)
GitHub Actions CI/CD for every commit/PR
Modern ESM/CommonJS packaging (works in Node, browsers, bundlers)
Zero runtime dependencies
API and deterministic output match Meteor’s original package
Easy migration: existing Meteor code should “just work” after changing the import.
Live interactive docs and playground
I’m migrating Meteor methods to a Fastify API for docs.bluehive.com and needed a drop-in replacement for Random.id() and Random.secret() that would behave identically—especially for session tokens and reproducible test data.
Features
Cryptographically secure: Uses crypto.randomBytes() (Node) or window.crypto.getRandomValues() (browser); falls back to Alea PRNG with entropy if crypto is unavailable.
API Compatibility: All Meteor Random methods supported:
import { Random } from '@bluehive/random';
const id = Random.id();
const secret = Random.secret();
const seeded = Random.createWithSeeds(42);
Deterministic output: Seeded generators produce the same sequence as Meteor’s implementation.
Character sets:
IDs: “Unmistakable” (avoids 0, 1, I, l, O)
Secrets: URL-safe base64
Hex strings: lowercase hex
Zero dependencies and modern JS packaging
Full coverage and test suite (89%+ coverage, 79 tests)
Works everywhere (Node, browsers, ESM/CJS, React/Next, etc.)
Splendid!
What do you think about extending the API? Over the years, I’ve run into a number of additional randoms that projects needed, which got partially recorded in the clinical:extended-api package. I’m thinking:
@wreiske this is awesome. One more somewhat related thing that should also be interesting for @awatson1978 - did you consider to look at the SHA256 function that is still used in Meteor core in many places (via sha package)?
I kept this private and reported it but nothing happened so I thought you might take a look at it.
Edit: I don’t want to spam / distort your post I just think its a great move to improve the overall security of Meteor and in my opinion that sha256 is also a part of it. If you think this is worth to work on then I will start providing a drop-in replacement for the sha package and PR to core