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

@ykstormsorg/anvil

v0.1.1

Published

Idempotent webhook to BullMQ worker pipeline — HMAC-SHA256 verify, dedupe, retry/backoff, dead-letter replay.

Readme

@ykstormsorg/anvil

npm CI license node

Idempotent webhook → BullMQ worker pipeline. The piece between a provider's webhook and your business logic: verify the signature, drop duplicates, enqueue one job, return 202 fast. A worker runs the job in the background on a fixed retry schedule, and a dead-letter queue holds whatever never succeeds.

Re-delivery is a real failure mode — Stripe re-sends, GitHub re-sends, your worker crashes mid-job. Most examples cover one step. Anvil covers the chain: verify → dedupe → enqueue → retry → dead-letter → replay.

Install

npm install @ykstormsorg/anvil
# needs a Redis instance (BullMQ runs on it)

Quick start

import { createServer, createWorker } from "@ykstormsorg/anvil";

// 1. Webhook ingress — verifies HMAC over the raw body, dedupes, enqueues, 202s.
const app = createServer({
  secret: process.env.WEBHOOK_SECRET!,
  redisUrl: process.env.REDIS_URL,      // default redis://localhost:6379
  signatureHeader: "x-signature",       // "sha256=<hex>"
});
app.listen(3000);

// 2. Worker — runs your handler, retries on [1s, 5s, 30s, 5m], then dead-letters.
const worker = createWorker(async ({ body }) => {
  const event = JSON.parse(body);
  await doTheWork(event);               // throw to trigger a retry
}, { concurrency: 8 });
await worker.start();

A re-delivered webhook (same signature + body) enqueues exactly one job, ever. The idempotency key is sha256(signatureHeader + rawBody), so a provider that rotates signatures on re-delivery still dedupes on the payload.

API

createServer(options) → Express app

Verifies the sha256=<hex> HMAC over the raw request body with a constant-time compare, computes the idempotency key, enqueues to BullMQ, and returns 202. A duplicate returns the original job's id without enqueuing again.

| option | default | meaning | | --- | --- | --- | | secret | — (required) | HMAC secret | | redisUrl | redis://localhost:6379 | BullMQ connection | | queueName | webhooks | main queue | | signatureHeader | x-signature | header holding sha256=<hex> |

createWorker(handler, options?) → { start, close }

Runs handler({ body, sig }, job). On a thrown error it retries on the backoff schedule [1s, 5s, 30s, 5m]; after the 4th failure the job moves to webhooks.dead with its failure context. The dead queue is written but never consumed here — replay is a separate process so a bad job can't drive a retry storm.

replayDeadLetter(jobId, options?) → { replayed, jobId }

Moves one dead-lettered job back onto the main queue. Run it from a CLI or a gated admin path, not inside the worker.

Known limitations

  • You map the provider's signature header yourself (signatureHeader); there's no per-provider preset yet.
  • Replay is one job at a time — no batch mode.
  • BullMQ + Redis is the only backend.
  • Raw-body access is required: do not express.json() before Anvil's verify, or the HMAC won't match.

Links

MIT © Lakshyaraj Singh Rao