npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details


  • User packages



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.


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 🙏

© 2022 – Pkg Stats / Ryan Hefner




The Elm Architecture for typescript





npm version build Coverage Status code style: prettier MIT license

The Elm Architecture for typescript


This is an implementation of The Elm Architecture (TEA) for typescript.

Note: TEA has managed effects, meaning that things like HTTP requests or writing to disk are all treated as data in TEA. When this data is given to an Effect Manager, it can do some "query optimization" before actually performing the effect. Your application should consist of pure functions only and all effects should be handled in Effect Managers outside your application.

TEA has two kinds of managed effects: commands and subscriptions.

How to use

yarn add @typescript-tea/core


Please see the documentation site.


This is the usual counter app example using the react as view library. It is also available in this repo.

import React from "react";
import ReactDOM from "react-dom";
import { exhaustiveCheck } from "ts-exhaustive-check";
import { Dispatch, Program } from "@typescript-tea/core";

// -- STATE

type State = number;
const init = (): readonly [State] => [0];

// -- UPDATE

type Action = { type: "Increment" } | { type: "Decrement" };

function update(action: Action, state: State): readonly [State] {
  switch (action.type) {
    case "Increment":
      return [state + 1];
    case "Decrement":
      return [state - 1];
      return exhaustiveCheck(action, true);

// -- VIEW

const view = ({ dispatch, state }: { readonly dispatch: Dispatch<Action>; readonly state: State }) => (
    <button onClick={() => dispatch({ type: "Decrement" })}>-</button>
    <button onClick={() => dispatch({ type: "Increment" })}>+</button>


const program: Program<State, Action, JSX.Element> = {

// -- RUN

const app = document.getElementById("app");
const render = (view: JSX.Element) => ReactDOM.render(view, app);, render);

Differences from TEA in Elm

There are some naming differences from TEA in Elm:

  • Msg was renamed to Action
  • Model was renamed to State

Elm is a pure language with strict guarantees and the Effect Managers are part of kernel in Elm and you cannot (for good reasons) write your own Effect Managers in Elm. Typescript is an impure lanauge without any guarantees so it (probably) does not make sense to have this restriction. Therefore in typescript-tea it is possible to write your own Effect Manager to do whatever you want.

It does not have a built-in view library, instead it is possible to integrate with existing view libraries like React.

How to import

Whole module from the root

This package (and others in @typescript-tea organization) exports only functions and types grouped into modules. You can import a module from the root of the package in the following way:

import { ModuleName1, ModuleName2 } from "@typescript-tea/package-name";

For example:

import { Result } from "@typescript-tea/core";

const result = Result.Ok("It is OK");

Unprefixed named imports from the module file

If you don't want to prefix with ModuleName you can also use named imports directly from the module file:

import { function1, function2 } from "@typescript-tea/package-name/module-name";

For example:

import { Ok } from "@typescript-tea/core/result";

const result = Ok("It is OK");

Modules that export a single type

A common pattern is to have a module that exports a single type with the same name as the module. For example the Result module does this, it exports the Result type, some constructor functions that create a Result type, and some utility funcitons that operate on or return a Result type. In these cases it can become annoying to prefix the type with the module name, like Result.Result. Consider the following example. Note that this is not how it is done for modules with single type exports in typescript-tea, it is just to illustrate how it would be done normally:

import { Result } from "@typescript-tea/core";

function itsOk(): Result.Result<string, string> {
  const ok: Result.Result<string, string> = Result.Ok("It is OK");
  const err: Result.Result<string, string> = Result.Ok("It is not OK");
  return ok;

To avoid having to write Result.Result in these cases, the Result module uses a trick so that both the module name and the type can be named simply Result. So the code above will become this (notice use of Result for the type annotations instead of Result.Result):

import { Result } from "@typescript-tea/core";

function itsOk(): Result<string, string> {
  const ok: Result<string, string> = Result.Ok("It is OK");
  const err: Result<string, string> = Result.Ok("It is not OK");
  return ok;

How can this work? Well, the index file in the package does this to make it work:

import * as ResultNs from "./result";

export const Result = ResultNs;
export type Result<TError, TValue> = ResultNs.Result<TError, TValue>;

I think it is somehow related to declaration merging in typescript :-).

Please note that this only work for modules that export a single type. If two types are exported it is not possible to use this shortcut because the exported const will not contain any types.

How to develop

Node version >=12.6.0 is needed for development.

To execute the tests run yarn test.

How to publish

yarn version --patch
yarn version --minor
yarn version --major