Rooks: 147 TypeScript React Hooks Split Across Three Entrypoints

What Rooks Solves, and Who It Is For

React ships a small set of hooks. Everything else, from reading a media query to running a callback on an interval while a condition holds, has to be written by hand or pulled from a library. Rooks is a collection of those hooks, written in TypeScript, published as a single package with multiple entrypoints, and licensed under MIT.

The README describes the package as "Focused, tree-shakeable, TypeScript-first React hooks for application state, browser APIs, events, timing, and UI behavior." That list of categories is the honest scope. If you need a data-fetching cache, Rooks is not that. If you need a counter, a toggle, a body-scroll lock, or a prefers-reduced-motion listener, it is.

The audience is React application developers on React 18 or 19 who already have a build step that handles ESM. The package is ESM-only, and the README states that plainly. That single constraint rules out some older toolchains before any hook is even imported.

Three Entrypoints Instead of One Barrel File

The design decision that separates Rooks from a flat hook dump is the entrypoint split. The README gives a table: `rooks` for stable hooks and explicitly exported utility types, `rooks/experimental` for hooks whose API or behaviour may change between minor releases, and `rooks/temporal` for hooks built on the JavaScript Temporal API.

The stated reason is dependency and compatibility surface. A hook that wraps a WebSocket has a different stability profile from a hook that wraps `useState`, so it lives behind a separate import path. The README warns that experimental hooks "can change in a minor release" and points to an experimental hooks guide before production use.

According to the generated hook catalog in the README, there are 147 canonical hook implementations: 118 in `rooks`, 25 in `rooks/experimental`, and 4 in `rooks/temporal`. Aliases are counted separately and, the README says, do not inflate that figure. The catalog also notes that only types exported by an entrypoint are importable, and that option and result shapes shown inline on a hook page are not necessarily public named exports. That is a real constraint on how far you can lean on the docs when writing your own wrappers.

The catalog zone is generated by a script rather than edited by hand, and CI verifies it with a check flag. That is a small thing, but it means the published counts are less likely to drift from the actual export barrels.

Installing Rooks and Writing a First Counter

The README gives the install command as pnpm. Any package manager that resolves npm packages will work, but the documented form is:

pnpm add rooks

The package requires React and React DOM 18 or 19, and it is ESM-only, so your bundler or runtime must handle ESM imports.

The quick start in the README uses `useCounter`, which returns a value plus increment, decrement and reset functions. Copy it into a component file:

import { useCounter } from "rooks";

export function Counter() {
  const { value, increment, decrement, reset } = useCounter(0);

  return (
    <section>
      <p>Count: {value}</p>
      <button type="button" onClick={decrement}>
        Decrement
      </button>
      <button type="button" onClick={increment}>
        Increment
      </button>
      <button type="button" onClick={reset}>
        Reset
      </button>
    </section>
  );
}

Render that component and you should see the count and three buttons that change it. The import path is the part worth noticing: it is bare `rooks`, not `rooks/experimental`.

If you want a Temporal-based hook, the README shows a second install step for the optional polyfill, needed where the runtime does not provide `Temporal`:

pnpm add @js-temporal/polyfill

And the corresponding import comes from the temporal entrypoint:

import { useTemporalNow } from "rooks/temporal";

The README notes that Temporal hooks require BigInt support and have specific SSR and time-zone considerations, with a separate guide covering them. Treat that guide as required reading rather than optional, because the failure modes there are runtime-specific.

Server Rendering Is Hook-Specific, Not Solved Once

The README is unusually direct about this: hooks that read browser globals handle server rendering in hook-specific ways. There is no single answer the library applies everywhere.

Two consequences follow. First, components still need a client boundary in frameworks where hooks cannot run in server components. Rooks does not remove that requirement. Second, permission-gated APIs need a fallback for unsupported or denied states. A hook that reads a browser capability can fail because the browser lacks it or because the user declined it, and those are different paths.

The README points to an SSR and browser APIs guide before using browser-only hooks in a server-rendered application. If your application renders on the server, budget time for that guide. The library gives you the hooks; it does not give you a uniform server story across them.

Where Rooks Is the Wrong Choice

The ESM-only constraint is the first hard boundary. The README states it without qualification. Projects whose build pipeline cannot consume ESM, or whose runtime resolves CommonJS only, will hit that wall before evaluating a single hook.

The second boundary is the experimental entrypoint. Twenty-five canonical hooks sit there, and the README says their API or behaviour may change between minor releases. If your policy is that no dependency may change behaviour on a minor bump, those hooks are not available to you under normal semver expectations. You can pin, but pinning a hook collection for the long term means you also stop receiving fixes elsewhere in the package.

The third boundary is scope. Rooks covers application state, browser APIs, events, timing and UI behaviour. It does not cover data fetching, caching, or form state management, and nothing in the README suggests it intends to. Reaching for it as a general React utility layer will leave you installing a second library for the parts it does not do.

One more caveat from the README: option and result shapes shown inline on a hook page are not necessarily public named exports. If you write wrapper hooks or generics around a Rooks hook, check the entrypoint's exported types rather than the inline signature in the docs.

How Rooks Differs From a Single-Purpose Hook Library

The obvious alternative is writing the hooks yourself. For `useCounter` or `useToggle` that is a few lines and no dependency. The trade-off is that a hand-written `useLockBodyScroll` or `usePrefersReducedMotion` accumulates the same edge cases the library already handles, and you own the maintenance.

A more interesting comparison is with libraries that bundle hooks around a single concern. Rooks is deliberately broad across categories and narrow within each: the README's catalog groups hooks into areas such as Animation and Timing, and lists each hook with a one-line description and its entrypoint. A library focused on, say, only browser APIs would give you a smaller dependency but nothing for timing or state.

The entrypoint split is the part that is genuinely different in approach. Rather than publishing one barrel where everything has equal stability, Rooks makes stability an import-path decision. You opt into the compatibility surface you need. That is more friction at the import statement and less uncertainty at upgrade time, and which of those you prefer is a policy question rather than a technical one.

Maintenance, Releases and the MIT Licence

The repository is not archived. The last push was on 2026-09-13. The most recent release recorded is [email protected] on 2026-08-16, preceded by [email protected] and [email protected] on 2026-06-21.

Versioning runs through Changesets. The root package.json defines `changeset`, `version-packages` and `release` scripts, and the version script also runs a script that bumps peer dependency ranges. The practical consequence for you is that peer dependency ranges on React are adjusted as part of the release process rather than left stale, which matters because the README pins support to React and React DOM 18 or 19.

The repository also carries a MAINTENANCE.md file at the top level. The README does not summarise what it says, so read it directly if continuity of maintenance is a factor in your decision.

On licensing: the package is MIT, and the repository LICENSE file is linked from the README badges. MIT is permissive and imposes no copyleft obligation on your application. That is a factual statement about the licence identifier, not legal advice; if your organisation has specific attribution or notice requirements, have someone review the LICENSE text rather than relying on the identifier alone. Note also that the optional Temporal polyfill is a separate package with its own licence, which the Rooks licence does not cover.

Editorial conclusion

Adopt Rooks if you want a maintained, MIT-licensed, ESM-only hook collection and you are prepared to import from the correct entrypoint: stable hooks from rooks, unstable ones from rooks/experimental, Temporal hooks from rooks/temporal. Do not adopt it if your build still resolves CommonJS only, or if you need a hook whose API is frozen across minor versions and you are not willing to pin. Before you commit, verify on your own React version that the specific hook you want is exported from the entrypoint you plan to import, check whether the hook you picked is one of the 25 experimental ones, and confirm whether your supported runtimes provide Temporal or need @js-temporal/polyfill. The last push to the repository was on 2026-09-13, and the most recent release recorded is [email protected] on 2026-08-16.

Frequently asked questions

Official sources

1. imbhargav5/rooks on GitHub
2. License: MIT
3. Project website
4. README
5. Releases