npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@forthtilliath/test-kit

v0.4.0

Published

Framework-agnostic test helpers: a `fetch()` mock response builder, a JSON fixture loader, an in-memory file system fake, and readers/writers for Zustand's persisted state — extracted from patterns duplicated across test files in this monorepo, none of th

Readme

@forthtilliath/test-kit

Framework-agnostic test helpers: a fetch() mock response builder, a JSON fixture loader, an in-memory file system fake, and readers/writers for Zustand's persisted state — extracted from patterns duplicated across test files in this monorepo, none of them tied to Expo or any other framework (see @forthtilliath/expo-test-kit for the Expo/Drizzle-specific ones: a real SQLite test database and an expo-file-system fake).

Install

npm install --save-dev @forthtilliath/test-kit

Or, from within this monorepo, as a workspace dependency:

{
  "devDependencies": {
    "@forthtilliath/test-kit": "workspace:*"
  }
}

Usage

Import everything you need from the package root, or one module at a time:

import { createMockResponse, loadJsonFixture } from "@forthtilliath/test-kit";
// or
import { createMockResponse } from "@forthtilliath/test-kit/createMockResponse";

createMockResponse(body, options?)

Builds a real fetch() Response resolving body — full API (clone(), blob(), arrayBuffer()…), assignable wherever a Response is expected. A string body is sent as-is; anything else is JSON-serialized, with a content-type: application/json header unless you pass one. ok follows the real rule (2xx only) unless forced with { ok }; a 204/205/304 status has no body. Wrap it in your test runner's own mock function — this package has no opinion on Jest vs Vitest.

vi.stubGlobal(
  "fetch",
  vi.fn().mockResolvedValue(createMockResponse({ id: 1 })),
);
// an error case:
vi.fn().mockResolvedValue(createMockResponse({}, { status: 404 }));

loadJsonFixture(importMetaUrl, relativePath)

Reads and JSON-parses a fixture file relative to the calling module, resolved from import.meta.url — the ESM-safe replacement for the CommonJS __dirname trick.

const release = loadJsonFixture<GithubRelease>(
  import.meta.url,
  "./fixtures/github-release.json",
);

createInMemoryFileSystem(initialFiles?)

A minimal in-memory file system (exists, readFile, writeFile, deleteFile, reset, and the underlying files map for direct inspection) — enough to test code that reads/writes files by path (e.g. via node:fs/promises) without touching the real disk.

const fakeFs = createInMemoryFileSystem({ "/config.json": "{}" });
vi.mock("node:fs/promises", () => fakeFs);

readPersisted(storage, key) / writePersisted(storage, key, state, version)

Read and write the { state, version } envelope Zustand's persist middleware keeps under its storage key — to check what a store saves on the device, or to plant the data an earlier app version left there and test the rehydration (and its migrate). storage is anything with getItem / setItem, sync or async: React Native's AsyncStorage (its Jest mock), the web's localStorage… readPersisted throws if nothing is stored, or if the value isn't such an envelope.

import AsyncStorage from "@react-native-async-storage/async-storage";

await writePersisted(AsyncStorage, "settings", { dark: true }, 1);
// …rehydrate the store, then:
await expect(readPersisted(AsyncStorage, "settings")).resolves.toEqual({
  state: { theme: "dark" },
  version: 2,
});

Scripts

pnpm run dev            # tsc --watch -> dist/
pnpm run build          # tsc -> dist/
pnpm run check-types    # tsc --noEmit
pnpm run lint           # eslint
pnpm run test           # vitest run
pnpm run test:watch     # vitest

Built to dist/ (see the exports field in package.json), so run pnpm run build (or dev) after source changes for consumers to see them.