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

@mindgrub/mindgrub

v0.1.22

Published

A collection of typed, platform-agnostic JavaScript functions.

Readme

Core tools

This repository contains general-purpose functions for use in Javascript runtime environments.

There are no runtime dependencies on other packages, nor any environment-specific API's. They only refer to ES2015 built-ins.

The build creates several distributables, including a single-file module bundle.

The module is intended to be used with Rollup as a packaging tool, and no particular effort is made to scope the content by subject matter.

The library is written in TypeScript and includes type definitions.

Note on modules

The JavaScript code here is written using the "ES2015" module format, and this is exported (by tsc) to AMD format. In places where module loading is wanted, it is assumed that an AMD-compliant require is in the global scope.

Note on explicit index reference

In intra-library imports, we do not take advantage of implicit index resolution, meaning that a statement like

import { flip } from './function';

which would work in TypeScript or Node.js, is instead written as

import { flip } from './function/index';

This is done to support Rollup, which, as is observed whenever anyone posts issues about this, does not use index to resolve imports:

That behaviour is Node and NPM specific and therefore not included in the core Rollup library. Please install rollup-plugin-npm to add the behaviour.

TypeScript quirks

TS4023 - Placeholder for notes about the export of type definitions. Currently, the public type definitions include both generated and authored type definitions. The postbuild task ships the authored definitions files, while the --declaration true option in build generates definitions in the output directory.

Documentation these decisions to follow. Bottom line, right now it's necessary to generate type definitions to meet all of the package's objectives, and as a result, there are a few places where annotations are necessary that wouldn't be otherwise. This compromise was chosen because TS issue threads indicate that a mitigation is marked for a future version, (I thought 2.7, but I can't find the link right now), where types will be transitively imported into generated declaration files, preventing the need for redundant annotations and imports.

UPDATE: With TypeScript 2.6 (now in RC), you can suppress errors in individual lines of TS files. This enables a cleaner solution than adding explicit type signatures, since you can simply import the referenced types and suppress the "unused local" error. This is the recommended approach for now.