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

umu

v0.0.2

Published

WIP - Execute `uvu` tests in real browser environments

Readme

umu

WIP: Execute uvu tests in real browser environments

Important: Currently only playwright is supported (WIP)! Important: The playwright and/or puppeteer APIs are not (currently) accessible to your test code.

Usage

Unlike uvu, the umu CLI is required (for now). The umu CLI manages browser orchestration, test bundling, and test execution.

Let's take a look at the CLI's help text:

$ umu --help
#
#   Usage
#     $ umu [dir] [pattern] [options]
#
#   Options
#     -C, --cwd         The current directory to resolve from  (default .)
#     -b, --bail        Exit on first failure
#     -i, --ignore      Any file patterns to ignore
#     -r, --require     Additional module(s) to preload
#     -B, --browser     The browser engine to launch. Must be one of "chromium", "firefox", or "webkit".  (default chromium)
#     -c, --coverage    Gather coverage information for source files. Requires "chromium" browser.
#     -d, --devtools    Open the Developer Tools panel. Requires "chromium" browser.
#     -H, --headless    Runs the browser in headless mode.  (default true)
#     -v, --version     Displays current version
#     -h, --help        Displays this message
#

If you're familiar with uvu, you'll notice that this is familiar. By design, the umu CLI is backwards compatible with the uvu CLI. This means that you can replace any previous instances of uvu with umu and your tests will automagically run inside a browser!

-$ uvu packages test -i fixtures -r ts-node/register
+$ umu packages test -i fixtures -r ts-node/register

You can customize the browser selection (playwright only) or browser execution settings through the additional option flags that umu brings.

Bundling

TODO:: This may become an optional step (See #3)

After matching test files, umu bundles each test file individually via Rollup. By default, umu includes the bare minimum amount of Rollup configuration so that your tests can be executed within the browser. This includes:

  • Producing a single-file bundle
  • Inlining all import and require statements
  • Replacing references to process.env, process.env.NODE_ENV, and process.browser
  • Including an inline source map

Any further customization – for example, defining import aliases, custom transforms, etc – must be handled through the umu.config.js file. Please see Config for more information.

Config

TODO: The format/keys will most likely change (See #2)

When defined, a umu.config.js file must export a function. It will receive two parameters:

Your function must mutate config (and options optionally) in order to produce a satisfactory Rollup configuration. The plugins tied to options are pushed into config.plugins for you.

Important: The config.output.format and config.output.sourcemap values are controlled.

Locations

A umu.config.js file can be defined anywhere that is accessible to your process.cwd() location.

Typically, you'll only ever need one configuration file per project, but there may be times where you need multiple configuration files per directory/workspace. In these cases, a configuration file will be automatically loaded depending on where umu is invoked.

Let's assume this project structure:

my-library
  ├── package.json
  ├── umu.config.js
  └── packages
    └── hello
      ├── umu.config.js
      └── test
        └── ...
    └── world
      └── test
        └── ...

And then let's assume we run the following commands from the project root (my-library):

$ umu packages test
#=> "hello" tests use `my-library/umu.config.js` (root)
#=> "world" tests use `my-library/umu.config.js` (root)

$ umu test --cwd packages/hello
#=> "hello" tests use `my-library/packages/hello/umu.config.js` (scoped)

$ umu test --cwd packages/world
#=> "world" tests use `my-library/umu.config.js` (root)

License

MIT © Luke Edwards