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

everkit-config

v0.6.0

Published

Shared build/lint/format/type tooling for Expo apps: a Babel config, an ESLint flat-config base, a Prettier config, a TypeScript base, and a Tailwind/NativeWind preset wrapper. Consumed as-is, no build step.

Readme

everkit-config

everkit-config is one shared set of house rules for how the code in our apps is written, checked and built. Tea Companion, Dial It In and Matcha Companion follow it, and so do the other everkit packages

The problem it solves

Every app needs the same behind-the-scenes setup. It needs rules for how code should look, checks that catch common mistakes, and settings that turn the code into a working app

When each app keeps its own copy of that setup, the copies slowly drift apart. One app gets formatted one way, another misses mistakes the first one catches, and changing a rule means changing it in every app by hand

everkit-config keeps a single copy of those rules. Each app points to it instead of keeping its own

What an app gets

  • One look for all code, so every file in every app is laid out the same way and reads the same
  • Automatic mistake checks, which flag common errors before they reach anyone using the app
  • Clear walls inside the app, which stop one part of the app from reaching into a part it should not touch
  • Shared build settings, so every app turns its code into a working app in the same way
  • Shared layout sizes, so the spacing and rounded corners from the everkit UI kit look the same everywhere
  • A check for written guides, which flags broken links, stale wording and details that quickly go out of date

An everyday analogy

Think of a small chain of cafés that share one recipe book. Each café has its own kitchen and its own menu extras, but the core recipes, measurements and hygiene checks come from the same book. When head office improves a recipe, each café picks up the change the next time it refreshes its copy, and a customer gets the same coffee wherever they order it

An app can still add its own extra rules on top, the same way a café can add a local special without rewriting the book

For developers: see ARCHITECTURE.md