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

@gryt/core

v0.2.0

Published

Gryt's shared application logic: one implementation of the things the desktop and mobile apps both do.

Readme

npm install @gryt/core

The desktop app and the mobile app carried a copy each of the same decisions. Some were real copies, some were the same idea written twice, and nothing told the two apart until somebody diffed them by hand. report.ts had the same seven exports on both sides and a different MESSAGE_MAX on each, 8000 against 4000, with nothing recording why.

They run this, not two ports of it. Both apps should pin the same version: a shared package on two versions is two implementations again.

What goes in here

Two questions, and a module needs both answers to be yes:

  • Would it compile with no DOM and no React Native?
  • Would both apps otherwise need a copy?

tsconfig.json enforces the first by leaving DOM out of lib, so document, window and localStorage fail to typecheck rather than working in one app and breaking in the other. The second is a judgement call, and the surface guard is what stops it drifting: scripts/check-public-surface.mjs fails when an export goes missing and when one appears that nobody listed.

What it is

  • reports — the shape Gryt-chat/reports takes, and how an app fills it in. Diagnostics is the union of what each platform can find out, so a renderer sends its Chrome build, a phone sends whether it's a simulator, and a field neither fills can be seen to be dead.
  • links — which site a URL belongs to, what colour to draw its card, what line to read out of its path, and which of four shapes a preview earns. 73 sites, seven of which also read a detail from the path.
  • profile — the pool of placeholder names a person gets before they pick one. Both apps handed these out and both files said to keep the other in step by hand.
  • permissions — the channel scope matrix: rules in, grid out, and back. The two apps keyed their cell map differently, a NUL on the desktop and a space on the phone, which is a key one of them could collide on.

What deliberately isn't

Anything needing a platform. Fetching is the clearest case: the desktop and the phone reach a server differently, so this decides what a link preview means and each app goes and gets it.

Artwork is the other one. A brand logo is a React component on the desktop and an SVG path or a favicon on the phone, so the package owns the hostnames, the colours and the path rules, and each app maps a provider id to its own icon.

@gryt/voice splits web and native behind two entry points because a media engine can't avoid the platform. This package has no such entry, on purpose. If one becomes necessary, that's a decision to make out loud rather than by adding DOM to the tsconfig.

Checks

npm test          # node --test, no runner to install
npm run typecheck
npm run build     # tsc to dist/, then rewrite specifiers for ESM
npm run check-surface

prepublishOnly runs the build, the tests and the surface guard, so a release that would have shipped a missing export fails before it leaves.

Issues

Please report bugs and request features in the main Gryt repository.

Sponsors

What sponsoring pays for, the tiers, and everyone who has sponsored: gryt.chat/sponsors. To sponsor: GitHub Sponsors.

The list itself lives in the Gryt README, in one place rather than ten, so it cannot fall out of step across repositories.

License

AGPL-3.0 — Part of Gryt

@gryt/ui is the exception in this org, and deliberately so: it's generic components with nothing of Gryt in them, and copyleft there would rule out most of the people who might use it.

This isn't that. It's the decisions the Gryt apps make, which is the product rather than scaffolding around it. It's still yours to embed, self-host and modify. The licence only bites for running a modified version as a closed service.