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

@syntopica/test-quality

v0.2.0

Published

Test-suite cost audit: find where a vitest suite spends its time and memory (DOM environments for DOM-free tests, files run twice, uncached local gates, hooks that repeat a gate)

Readme

@syntopica/test-quality

Test-suite cost audit for vitest projects: finds where a suite spends its time and memory on work that is not testing. Each finding is a measurement or a reading of the project's own config, with the evidence that makes it checkable.

Every finding is an error and fails the command; there is no warning level. What asks for no change (timings, memory, what a hook runs) is printed as an observation beside the findings and never fails anything.

Built from one suite's diagnosis (verticagtm, 2026-10-04): building a jsdom window per file was 61-72% of the work while two thirds of the files never touched it, a projects split ran every file twice without failing, and the pre-push hook ran ESLint and Prettier cold. Fixing those took the suite from 106-131 s to 72 s and the pre-push hook from 417-547 s to 228 s.

Install

pnpm add -D @syntopica/test-quality

vitest (3 or later) must be installed in the audited project; the tool loads it from there.

Usage

codeality-test check [--json]
codeality-test measure [--json] [--node-candidates] [--top <n>] [-- <vitest args>]

--project <dir> before the command runs against another directory.

check executes nothing. It asks the project's vitest which files it runs, in which project and environment, and reads package.json with lefthook.yml or .husky/:

| finding | meaning | | -------------------- | ----------------------------------------------------------------------------------------------- | | duplicate-file-run | a file two projects both run; with extends: true a project's include is added to the root's | | uncached-hook-lint | ESLint or Prettier reached from a git hook without --cache |

| observation | meaning | | ---------------------------- | --------------------------------------------------------------------------- | | dom-environment-candidates | files under jsdom/happy-dom whose source names no DOM API: guesses for node | | hook-runs-full-gate | a hook reaches the static gate and the whole suite |

measure runs the suite once, with vitest's JSON reporter beside the default one, sampling the resident memory of vitest and every worker once a second:

| finding | meaning | | ------------------------ | ------------------------------------------------------------------------- | | environment-dominates | environment setup is over 40% of the work and outweighs the tests | | dom-environment-unused | with --node-candidates: candidates that pass under --environment node |

| observation | meaning | | --------------- | ------------------------------------------ | | suite-run | vitest's exit code and the run's wall time | | slowest-files | the --top slowest files (default 10) | | memory-use | peak and mean RSS of the run |

The candidate list is deliberately broad on the DOM side: a file that names window, render, @testing-library/... and the like is never proposed, and the node rerun decides for the rest. Move the files that pass to a node project and give the few that need a window a // @vitest-environment jsdom docblock.

Hosted CI is not flagged for running ESLint cold: a cache can hold typed-rule results that a change elsewhere made stale, so a cold run there is the backstop for the cached local gate.

Exit codes

0 no findings, 1 findings (observations never count), 2 invalid usage or configuration (including a project vitest cannot list), 3 anything else.

JSON

--json prints { "schemaVersion": 2, "findings": [...], "observations": [...] }. A finding is { rule, severity: "error", message, evidence }; an observation is { name, message, evidence } and has no severity.