# Radashi: a tree-shakeable TypeScript utility toolkit > Radashi is a dependency-free TypeScript library of small, typed utility functions, forked from Radash and run by a community-first group. It fits teams that want Lodash-like coverage without the bundle weight, and it is a poor fit for state management or anything requiring a framework runtime. **radashi-org/radashi** — The modern, community-first TypeScript toolkit with all of the fast, readable, and minimal utility functions you need. Type-safe, dependency-free, tree-shakeable, fully tested. - Repository: https://github.com/radashi-org/radashi - Website: https://radashi.js.org - Stars: 968 · Forks: 73 - Language: TypeScript - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/radashi-org-radashi ## Radashi is a fork of Radash with a different governance model Radashi is a community-maintained fork of Radash, the library that positioned itself as a faster growing alternative to Lodash. The README is explicit about the relationship and points to a comparison post on the project site for the details of what changed, and states that the goal is bringing Radash to the next level while preserving its best features. What actually differs is the process rather than the code. The README explains that community first means putting community needs first, leaning towards adding support for popular use cases as opposed to being strictly minimalist, and that feedback is collected through discussions in an RFCs category. Contributions are encouraged but should be small and focused, and sweeping changes are discouraged unless the rationale has been thoroughly discussed. Maintainers are recruited from the contributor pool, with reviewing and triage as the entry steps and merging rights earned over time. That governance choice has a direct consequence for a user. A strictly minimalist library can say no to most requests. A community-first one accumulates functions that popular use cases need, which is why the library describes itself as unique and well-designed rather than small. The trade-off is a surface area that grows between major versions, and the README says so in plain terms with a migration note for anyone arriving from radash. The project is also honest about where it came from, which is unusual for a fork and useful context for anyone weighing trust in a young package. ## Dependency-free and tree-shakeable, with scripts that police both claims The three properties that decide whether Radashi fits your project are stated plainly: type-safe, dependency-free and tree-shakeable. The README adds full test coverage, performance tracking through continuous benchmarking, and modern ES6+ syntax. Two entries in the package.json scripts turn those claims into checks rather than marketing. The build runs tsup --clean, and there is a tree-shake-check script that runs the repository's own tree-shake routine, plus a bundle-impact script. That combination means the project measures what ends up in a consumer bundle after tree shaking, which is the number that decides whether a utility library is worth adding at all. There is also a benchmarks/ directory and a bench script backed by vitest bench. The dependency-free claim is verifiable from the package manifest. Every entry under devDependencies is tooling for the repository itself: Biome for linting and formatting through a shared config, vitest with v8 coverage, cspell for spelling, prettier with plugins for package and shell files, and type definitions for Node. The published artifact contains dist only, per the files array, and the package exports point at a CommonJS build, an ESM build and matching type declarations for each. The package is ESM first, with "type": "module" in the manifest, and it still ships a CommonJS entry, so both module systems are covered. Engines require Node 16.0.0 or later, and pnpm 10.29.3 is the declared package manager. ## Installing radashi with pnpm, yarn or npm Installation is a single dependency add, and the README lists all three major package managers: ```bash pnpm add radashi ``` ```bash yarn add radashi ``` ```bash npm install radashi ``` Pick the one matching the rest of your workspace. The repository itself uses pnpm, and pnpm-lock.yaml sits at the top level alongside the lockfile-driven renovate.json for dependency updates. After the install you import the functions you need by name rather than pulling in a namespace. The README frames this as use only what you need, which is the tree-shaking claim applied to your import style. Nothing in the manifest prevents a large namespace import, but the tree-shake-check script in the repository exists precisely to detect when a change adds weight that survives bundling. A few other things worth knowing before you start. The docs live at radashi.js.org, and the source tree is src/ with tests/ alongside it. The build output is generated by tsup and the dev script, tsup --clean --watch --sourcemap, rebuilds on change. The CLI has its own subcommands for repository work, including radashi fn create and radashi fn move, which are for adding or relocating a function inside the project rather than for calling the library at runtime. There is also a skills/ directory at the top level of the repository and a deno.json file, which points at the JSR distribution discussed below. ## Beta, next and canary: three channels for pre-release code The release system is unusually layered, and it is worth understanding before you point CI at a tag. Beta versions are published regularly with new functions and improvements, and the README states they never contain breaking changes. The source for a beta lives on the beta branch of the repository. Installation goes through the beta dist-tag with an exact version pin: ```bash pnpm add radashi@beta -E ``` The -E flag is there for a reason: it makes the install exact, for example radashi@12.3.0-beta.abc1234, and the README recommends it to avoid accidental breakage when the beta tag moves. Notification of new beta releases comes from the separate radashi-canary repository, which also holds the release notes for beta versions. A parallel channel exists for the next major version. Preview releases for the next major are announced in the same radashi-canary repository, and the source code for the next major lives on the next branch. The same exact-pin pattern applies: ```bash pnpm add radashi@next -E ``` The project asks people to try that build and report problems before it ships. For most teams the practical rule is simple: pin the beta or next version exactly, never track the tag, and treat both as test surfaces rather than dependencies. What the README does not give is a published schedule for major releases or a stated support window for a given major line, so planning around a major upgrade means watching the changelog and the canary announcements. ## Automatic releases triggered by commit prefixes and labels Two release paths are automated by workflow rules rather than by hand, and they are worth knowing because they tell you how quickly fixes reach npm. Patch releases happen whenever the main branch receives a commit whose message begins with ^fix:, and a patch release is published to npm immediately. The caret prefix in that convention is specific, and it means the release cadence for bug fixes is tied to how the repository writes commit messages. The commitlint.config.ts file at the top level suggests commit messages are linted, and cliff.toml with .cliffignore configure the changelog generation, with CHANGELOG.md as the output the README links for seeing what changed in each release. Beta releases are triggered differently. A pull request that adds a new feature can be labelled with prerelease by a maintainer, which sets off a GitHub workflow that attempts to copy the pull request into the beta branch, and if that copy succeeds a beta release is published to npm immediately. Two things follow. First, the branch model matters: contributions land on main, fixes flow straight to npm, and features take the longer path through the beta branch. Second, the beta channel depends on an automated copy step, so a conflict during that copy can delay or prevent a beta build, which is why the exact version pin matters. Recent versions give a sense of rhythm without needing a promise: v12.9.4 on 2026-09-14, v12.9.5 on 2026-09-17 and v12.9.6 on 2026-09-21. ## JSR publishing covers Deno and TypeScript-native consumers Radashi is also published to the JSR registry, which gives it its own page there. The README explains that this is a second distribution channel, and the install commands are different from npm: ```bash jsr add @radashi-org/radashi ``` ```bash deno add jsr:@radashi-org/radashi ``` The scoped name @radashi-org/radashi on JSR differs from the plain radashi package on npm, so a migration between the registries is not a matter of changing the version number. The deno.json file in the repository root confirms Deno is a first class target rather than an afterthought, and the Node typings in devDependencies show the TypeScript types are produced for both environments. The reason this matters for an adopter is that JSR packages are consumed with their types resolved by the runtime's own tooling rather than through a separate @types package. If your team standardises on Deno or on a JSR-aware TypeScript setup, the npm installation path is the less natural one. Everything else about the library behaves the same across both channels. The licence is MIT, the LICENSE.md file sits at the top of the repository, and the same tree-shaking and dependency-free properties are claimed for the published build regardless of registry. ## Migrating from the radash package is an explicit, supported path Because Radashi is a fork of Radash, the two packages coexist in the wild, and the README treats the transition as a first class concern. Backwards compatibility is stated as a goal, and the guidance for people arriving from radash is to install radashi@^12, a line that will continue to receive backported fixes even after Radashi v13 is released, with the upgrade to the latest major left to when you are ready. That is a mild name confusion worth flagging. The package named radash and the major version named Radashi v13 refer to different things, and the guidance to stay on radashi@^12 while upgrading the underlying library is exactly the kind of detail that gets lost in a migration ticket. The documentation also points at the ethos of Radashi before you contribute, and states that sweeping changes are discouraged and will not be merged unless the rationale has been thoroughly discussed. For a company that wants to propose a substantial API change, that is a political fact about the project, not just a process note: the route is an RFC discussion in the organisation's discussions area, and the FAQ invites exactly that when a needed function does not exist. Security is handled through a SECURITY.md file at the top of the repository, alongside the standard contribution and changelog files. ## Where Radashi is the wrong tool Radashi is a function library, and the boundary shows up in what it refuses to do. There is no state management, no data fetching layer, no component model and no framework integration in the package manifest or the documented feature list. If your need is a cache with stale-while-revalidate semantics, a query layer, or a normalised store, nothing here provides it, and the README is not ambiguous about that. The second boundary is about the size of what you need. Because the project leans towards popular use cases over strict minimalism, the surface grows, and a team that only wants three helpers is paying for a dependency it will use lightly. The mitigations exist and are real: the package ships only dist, it has no runtime dependencies, and tree shaking is enforced by a check in the repository's own scripts. But a bundle impact script in the maintainers' repository is not the same as a measurement in your application, so the practical step is to look at your own bundle after the install rather than assume. The third boundary is churn. Automatic patch releases mean fixes arrive quickly, and feature additions land in betas and then majors. A team that pins to the latest 12.x gets frequent updates; a team that wants stability has to pin and read the changelog. The README offers no long term support branch. The alternative to a general purpose toolkit is writing the helpers you actually use yourself, or importing a single focused package per need. The difference in approach is ownership: Radashi gives you a maintained, typed, tested surface with a migration story from radash, at the cost of a dependency that grows over time. ## Conclusion Adopt Radashi when you are replacing Lodash or hand-rolled helpers in a TypeScript codebase and want per-function tree shaking with a large typed surface, and skip it when your need is state management, data fetching or a framework-integrated data layer, since none of that is in scope here. Verify three things before you migrate: that the functions you actually call exist in the current release, since the API surface moves between majors, that radashi@^12 keeps receiving backported fixes if you are coming from the radash package, and that your bundler handles the package exports map correctly for the ESM and CommonJS entry points. The last push to main was on 2026-10-19 and version 12.9.6 was published on 2026-09-21, so the release train is regular, and the changelog at CHANGELOG.md is the place to check what a given bump changed. ## FAQ ### How do I install Radashi? Add it with your package manager, using pnpm add radashi, yarn add radashi or npm install radashi. The published package has no runtime dependencies, ships only dist and requires Node 16.0.0 or later. ### What is the difference between Radashi and Radash? Radashi is a community-maintained fork of Radash that preserves its best features while changing how the project is run, leaning towards popular use cases rather than strict minimalism. The project documents the differences in a comparison post and points Radash users at radashi@^12, which keeps receiving backported fixes. ### How do I install a beta version of Radashi safely? Run pnpm add radashi@beta -E. The -E flag pins an exact version such as radashi@12.3.0-beta.abc1234 instead of tracking the moving tag, and beta releases never contain breaking changes. ### Can I use Radashi with Deno? Yes. Radashi is published to the JSR registry as @radashi-org/radashi, installed with jsr add @radashi-org/radashi or deno add jsr:@radashi-org/radashi, and the repository includes a deno.json file. ### Does Radashi have runtime dependencies? No. The project describes itself as dependency-free, and the package manifest lists only development tooling such as Biome, vitest, cspell and prettier, with the published files limited to dist. ## Sources - [License: MIT](https://github.com/radashi-org/radashi/blob/main/LICENSE) - [Project website](https://radashi.js.org) - [radashi-org/radashi on GitHub](https://github.com/radashi-org/radashi) - [README](https://github.com/radashi-org/radashi/blob/main/README.md) - [Releases](https://github.com/radashi-org/radashi/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/radashi-org-radashi