I'm Shipping 5 npm Packages to 10,000 Downloads

Paras — Wed, 11 Nov 2026 17:59:05 +0000

I'm Shipping 5 npm Packages to 10,000 Downloads

This is the first post in a series. The goal is simple: get my five npm packages to 10,000 combined downloads before the end of the year. I'm going to write about every step — what I ship, what works, what doesn't, and the real numbers.

No growth hacks. No threads about "how I made $10k in a month." Just shipping, twice a day, and writing down what happens.

Where I started

I have five packages. As of this morning (Nov 11), their combined downloads are 4,153. That leaves 5,847 to go.

The five:

plumber-linter — a CI/CD pipeline linter that flags hardcoded secrets, leaked credentials, and dead code, with fixes in plain English. 1,340 downloads.
environmental-peek — safely inspect .env files without leaking secrets. Mask values, diff against .env.example, generate .env.example. 962 downloads.
hexlens — a binary analysis tool. Parse PE, ELF, Mach-O, WASM, DEX and .NET, with strings, graphs, and now YARA rule scanning. 840 downloads.
react-dismiss — a tiny React hook that dismisses dropdowns, popovers and modals on outside click or Escape. 563 downloads.
@parasraju/plumber-mcp — the plumber-linter engine as an MCP server, so AI coding tools can scan pipelines too. 448 downloads.

What I learned so far

Downloads don't grow steadily. They spike on publish days and go flat otherwise.

The numbers from my own packages: a publish day spikes around 200 downloads. A flat day is 0 to 10 per package, 30 to 50 combined. It doesn't matter much whether the release is big or small — every publish spikes, even a bug-fix patch. The day after a publish there's a small tail, then it's back to flat.

So the strategy writes itself: ship twice a day, every day. One feature in the morning, one in the evening. Medium features, not just bug fixes. Every publish gets a version bump, a README touch-up, and better keywords, because ranking is part of shipping.

The last two days proved it: +406 downloads one day, +397 the next, right after the twice-a-day shipping started.

The rules I'm playing by

Update the existing five. No new tools. New ideas are tempting, but five packages with real users beat ten half-built ones.
Two ships a day, 11am and 9pm. If I miss one, I do the next one. No doubling up.
Every ship is a real feature. Not version bumps for the sake of it.
Write about it. That's what this series is.

What this series will be

Each post covers a ship or a lesson: what changed in the package, why, and what the numbers did after. The wins and the misses. When something breaks — and it will — I'll write about that too.

If you build tools, ship packages, or you're trying to get your own project past the flat-days problem, follow along. And if you've used any of the five, try the latest version and tell me what it missed. That's the fastest way to make the next release better.

The counter starts at 4,153. Let's see how fast it moves.

🔗 npm: https://www.npmjs.com/~parasraju
💻 GitHub: https://github.com/parasraju

Part 1 of the series "Shipping 5 npm packages to 10k downloads".

Your CI/CD Pipeline Is the Easiest Way Into Your Repo (And Nobody's Checking It)

Paras — Wed, 11 Nov 2026 16:18:51 +0000

Your CI/CD Pipeline Is the Easiest Way Into Your Repo (And Nobody's Checking It)

Your code gets reviewed. Your dependencies get scanned. But your CI/CD pipeline — the thing with access to your secrets, your deployments, and your production credentials — usually gets copy-pasted from a tutorial and never looked at again.

That's the gap plumber-linter was built for.

The problem hiding in plain sight

Here's a workflow file that looks completely normal. It's also a security incident waiting to happen:

name: CI
on: [push]

permissions: write-all

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: some-random-action/setup-node@main
      - run: |
          echo "Deploying..."
          curl -H "Authorization: Bearer AKIAIOSFODNN7EXAMPLE" https://api.example.com/deploy

Three problems, zero warnings from your CI:

permissions: write-all — the workflow can do everything: push code, read secrets, modify releases. A compromised step inherits all of it.
An unpinned action (@main) — you're running whatever the maintainer pushes next, sight unseen. If that repo gets hijacked, so does your pipeline.
A hardcoded secret in a run step — it now lives in your git history forever, and anyone with repo access can read it.

Most teams find these during an incident review. plumber-linter finds them before that.

What it checks

plumber-linter scans your CI/CD pipeline configs — GitHub Actions and GitLab CI — and flags:

Hardcoded secrets in workflow files
Overly broad permissions like write-all
Unpinned third-party actions that can change under you
Missing branch protections that let unreviewed code straight into main

And instead of cryptic rule IDs, it explains each finding in plain English — what the risk actually is, and how to fix it. So even if you're not a security person, you know exactly what to change and why.

What's new in v1.2.0

The latest release adds 5 new rules, and they cover the stuff I kept seeing in real repos:

Unpinned Docker images — image: node:latest in your workflow means your build changes whenever the image does. Pin it.
curl | bash — piping a remote script straight into your shell in CI. If that server is compromised, your runner is too.
permissions: write-all — now flagged as its own high-severity rule, not buried in a generic check.
Slack webhooks in plain text — a leaked webhook URL lets anyone post to your channel. It gets flagged the same way a leaked API key does.
Unpinned npm packages in CI — npm install some-package@latest in a pipeline is the same unpinned-action problem, one layer down.

That brings it to 26 rules total. One command, whole pipeline checked.

Try it on your own repo

npm install plumber-linter

plumber .

It takes seconds. If it comes back clean, good — your pipeline is in better shape than most. If it flags something embarrassing, that's the whole point. Fix it, and your next deploy is already safer than your last one.

Why I built it

Pipeline security tools exist, but they're usually heavy, noisy, or written for security teams. I wanted something a regular developer could run in a minute and actually understand the output of. No 200-page report — just the real risks, explained like a person would explain them.

plumber-linter is at v1.2.0 now, with 1,300+ downloads on npm and counting. It's still early, and it's getting better with every release — if you run it on your repo and it catches something, or misses something it should have caught, I'd genuinely love to hear about it.

Try it, break it, and tell me what it missed. Feedback welcome.

🔗 npm: https://www.npmjs.com/package/plumber-linter
🌐 Website: https://plumber-7dv.pages.dev/
💻 GitHub: https://github.com/parasraju/plumber

Built for GitHub Actions / GitLab CI. npm install plumber-linter

DEV Community: Paras

I'm Shipping 5 npm Packages to 10,000 Downloads

I'm Shipping 5 npm Packages to 10,000 Downloads

Where I started

What I learned so far

The rules I'm playing by

What this series will be

Your CI/CD Pipeline Is the Easiest Way Into Your Repo (And Nobody's Checking It)

Your CI/CD Pipeline Is the Easiest Way Into Your Repo (And Nobody's Checking It)

The problem hiding in plain sight

What it checks

What's new in v1.2.0

Try it on your own repo

Why I built it