radashi
A dependency-free, tree-shakeable TypeScript utility toolkit and community-maintained fork of Radash.
Repository Health
Technical Analysis
Radashi is a TypeScript utility toolkit built as an actively maintained fork of Radash, the popular Lodash alternative that outgrew its original maintenance capacity. It packages hundreds of small, well-typed helper functions for arrays, objects, strings, numbers, async control flow, currying, and type guards into a single dependency-free package that is fully tree-shakeable, so consumers only pay for the functions they actually import.
The project differentiates itself less on the functions themselves (many mirror familiar Radash/Lodash conventions) and more on its process: 100% test coverage is enforced in CI, every function ships full JSDoc with a documentation-site cross-reference and a runnable example, and a label-driven release pipeline pushes patch, beta (radashi@beta), and next-major (radashi@next) builds to npm automatically from merged pull requests, giving contributors an unusually fast path from PR to published release.
What You Get
- Hundreds of small, single-purpose utility functions across array, object, string, number, async, curry, oop, random, and type-guard modules, each isolated in its own file under src/
- Full TypeScript type inference on every function, including precise generic return types (e.g. group() returns an accurately-typed partial record)
- A dependency-free, tree-shakeable dual ESM/CJS build with 100%-enforced test coverage on every merged change
- Access to nightly beta (radashi@beta) and next-major (radashi@next) prerelease channels for trying upcoming changes before they land on the stable release
- A companion documentation site (radashi.js.org) with a per-function reference page generated directly from source JSDoc
Common Use Cases
- Replacing ad hoc array/object helper code (grouping, deduping, diffing, chunking) with tested, typed utility functions
- Wrapping async operations with typed retry/timeout/queue/parallel helpers instead of hand-rolled Promise plumbing
- Migrating off Lodash or the original Radash for a smaller, tree-shakeable, actively-maintained alternative
- Building safe error-handling flows with Result-style helpers (tryit, toResult) instead of try/catch boilerplate
- Converting string casing for codegen, forms, or API payload normalization (camel, snake, dash, template)
Under The Hood
Architecture Radashi is organized as a flat, category-based module structure — src/ is split into functional domains (array, async, bigint, curry, function, number, object, oop, random, series, string, typed), each holding one function per file, all aggregated into a single barrel file (src/mod.ts) that re-exports every function. There’s no class hierarchy, dependency injection, or shared runtime state — it’s a pure-function library where each file is largely self-contained, importing only from the typed/ predicate module (isFunction, isArray, isNullish, etc.) when it needs internal type-guarding, making that module the closest thing to a shared abstraction whose change would ripple broadly. Build tooling (tsup.config.ts) compiles mod.ts into a single CJS/ESM bundle (dist/radashi.cjs, dist/radashi.js) with matching type declarations, and the one-function-per-file layout combined with sideEffects:false in package.json guarantees per-function tree-shaking for consumers.
Tech Stack The project is written in TypeScript 5.5 and built with tsup (an esbuild-based bundler) to produce dual CJS/ESM output plus .d.ts/.d.cts declarations. Linting and formatting run through Biome (extending a shared @radashi-org/biome-config), with Prettier handling non-JS/TS files. Tests run on Vitest with v8 coverage and a typecheck pass over dedicated .test-d.ts files. The package has zero runtime dependencies, uses pnpm as its package manager, targets Node >=16, and is published to both npm and JSR. An extensive GitHub Actions suite (check-main, check-pr, bench-pr, publish, prerelease-pr, register-pr) automates patch/beta/next releases directly from pull request activity, and a companion docs site is generated and deployed via publish-docs.yml.
Code Quality The tests/ directory mirrors src/ one-to-one (tests/array/group.test.ts pairs with src/array/group.ts, and so on), using Vitest’s describe/test/expect API alongside type-level assertions in *.test-d.ts files. vitest.config.ts sets coverage thresholds to 100 across src/**, meaning contributions must keep full statement coverage to merge. Error handling favors explicit, typed results over exceptions where it matters most — tryit.ts and toResult.ts wrap functions/promises into typed result tuples instead of relying on try/catch — and naming is consistent camelCase, one file per exported symbol. Every exported function carries a JSDoc block with a description, a @see link to its documentation page, a runnable @example, and a @version tag, giving the codebase extensive self-documentation on top of its test coverage.
API Design
Radashi’s functions read as natural verbs (group, boil, diff, fork, sift, cluster) with a consistent data-first argument order, and TypeScript generics infer return shapes precisely — group()‘s return type reflects partial keys automatically, so consumers get accurate optional-property hints without manual casting. Getting started requires no boilerplate beyond a single import * as _ from 'radashi' or named imports, and because the package is dependency-free and tree-shakeable, bundle cost scales only with what’s actually imported. The documentation site is generated per function straight from source JSDoc, keeping docs and implementation in sync. Conceptually the API isn’t especially novel — it’s explicitly a maintained continuation of Radash’s design — but the automated patch/beta/next release pipeline wired directly to PR labels is a distinctive process-level innovation that shortens the usual contribution-to-release cycle for a utility library.