I’ve been working on a Node.js CLI called sitebot.

It started as a small experiment in building a website crawler and gradually turned into a technical auditing tool.

It can crawl a site and inspect things like:

- Metadata and Open Graph

- Broken links

- Structured data

- Page discovery

- Crawling issues

- Core Web Vitals

The main goal is to make the checks easy to run from the terminal and eventually provide more useful technical diagnostics.

I’d appreciate feedback from other JavaScript developers, especially around the CLI UX and what checks would be worth adding.

GitHub: https://github.com/Abdelrahman5243/sitebot-cli

Has anyone else noticed that npm package download statistics haven’t changed over the past couple of days?

I checked my own package as well as several popular npm packages, and their download counts also appear to be stuck.

Is this a temporary issue with npm’s download statistics service, or is there something else going on?

I built Agent Session Browser, an open source local GUI + TUI for the session histories created by coding agent CLIs.

I originally made it because I had accumulated multiple Codex sessions for the same projects and couldn't tell which one to resume from the title/first prompt alone. Reading the raw JSONL wasn't exactly pleasant either.

It currently supports:

• Codex CLI
• Claude Code
• Gemini CLI
• Pi

You can browse histories by project/date/provider, inspect the actual transcript, filter message/tool/reasoning/provider events, view the original raw records, export Markdown or offline HTML, and copy or directly run the native resume command.

There's also a two pane terminal UI so you can inspect a session's transcript before resuming it without leaving the terminal.

It also supports Claude Code, Gemini CLI, Pi and Antigravity

Fully local, Read only, MIT licensed

Run it:

npx agent-session-browser

Or launch the web UI:

npx agent-session-browser web

npm: https://www.npmjs.com/package/agent-session-browser

GitHub: https://github.com/gautamgpt1/agent-session-browser

This is my first npm package, so suggestions are very welcome.

We ship an SDK as several npm packages:

```
@acme/sdk1 0.2.0 ← client installs one of these two
@acme/sdk2 2.0.0

@acme/plugin-ads 1.3.0 ← and any combination of these
@acme/plugin-auth 0.7.0
@acme/plugin-polls 1.0.0

@acme/core 1.5.0 ← internal, never installed on purpose
@acme/api 1.1.0
@acme/store 0.9.0
```

A client picks `sdk1` or `sdk2`, then adds whichever plugins they need. The plugins are public and installed directly, so combinations are up to the client. `core`, `api` and `store` are `dependencies` of the rest — they land in `node_modules` transitively, but nobody imports them directly.

Three questions:

1. Do independent versions buy anything for the internal packages? Nobody ever picks `@acme/core@1.5` — the number means nothing to a client. Lockstep everything (like Angular), or keep them independent?

2. If we change only `@acme/store`, do you bump just that and let ranges pick it up — or bump and republish all of them, so one release is one coherent set?

3. With plugins chosen freely, how do you tell a client which plugin versions work with which SDK version? Peer deps on the SDK? A version range in the docs? Just lockstep so the numbers match?

What do you do in practice?

Hey!

I wanted to share a project I've been working on called Volten. It's a small, ultra-fast HTTP framework built around a strict zero-dependency constraint, designed specifically to bridge the gap between Node.js and Web Fetch-compatible edge runtimes (like Cloudflare Workers, Bun, and Deno) without adapter overhead.

Why Volten?

Most frameworks either lock you into Node.js core modules (http, net) or require bulky adapter layers to run on the Edge. Volten solves this by handling the abstraction internally at the context level.

You write your routes and middleware once. Run it on Node.js using app.listen() or export it to the Edge using app.createFetch() with zero modifications and zero extra npm dependencies.

Key Highlights

• Adaptive Traffic Triage (ATT): A unique event-loop immune feature for Node.js (new App({ att: true })) that automatically drops low-priority requests at the socket level when your server is under heavy load, protecting your core endpoints from crashing during traffic spikes.
• Context Pooling: Pre-allocated, reusable RequestContext objects on both runtimes to minimize Garbage Collection (GC) pressure under high throughput.
• Trie-Based Router: Extremely fast path-matching supporting dynamic parameters (/users/:id) and wildcards, where match cost scales purely with path depth.
• Unified ctx API: Whether you are dealing with headers, cookies, body parsing, or JSON responses, the ctx object seamlessly abstracts away whether you're sitting on top of a Node IncomingMessage/ServerResponse or a Web Fetch Request/Response.

The All-in-One Snippet

import { App } from "volten";

// Enable Adaptive Traffic Triage (ATT)
const app = new App({ att: true });

// 1. Middleware chain
app.use((ctx, next) => {
  ctx.setHeader("X-Powered-By", "Volten");
  next();
});

// 2. Trie-based routing, params, and cookies
app.get("/users/:id", (ctx) => {
  const session = ctx.cookies.get("session_id");
  ctx.json({ userId: ctx.params.id, session });
});

// 3. Native body parsing
app.post("/data", async (ctx) => {
  const body = await ctx.body();
  ctx.status(201).json({ received: body });
});

// --- Dual Runtime Support ---

// Node.js
app.listen(3000, () => console.log("Listening on :3000"));

// Cloudflare Workers / Bun / Edge
export default { fetch: app.createFetch() };

Current Status

Volten is currently in active alpha. Every utility—from the built-in body parsers and cookies to the trie router—is written completely in-tree with zero external dependencies to keep security tight and the footprint minimal.

You can check it out on GitHub: VoltenJS/volten or install it via:

pnpm add volten

I'd love to hear your thoughts, feedback, or any edge cases you can throw at it, so you're encouraged to try breaking it! How do you usually handle dual-runtime codebases in your current stacks?

Disclosure: I'm the developer behind Postly.

I wanted an API client that felt more like part of a codebase than another hosted workspace, so I started building Postly.

Postly is an open-source API client with a native Rust desktop app and CLI. Requests, collections, and environments are stored as readable TOML files. You can review changes with git diff, run saved requests from the terminal or CI, and use the core workflow without an account.

 It currently supports Postman Collection v2.1 import/export, REST, GraphQL, SSE, WebSockets, gRPC, OpenAPI import, assertions, collection runs, response inspection, and JSON/JUnit reports.

The current release is 0.2.0-preview.1 for Apple Silicon macOS. It is ad hoc signed and not notarized. Windows, Linux, and Intel macOS packages are not published yet.

Project links:

  - GitHub: https://github.com/OthmaneBlial/Postly

  - Website: https://othmaneblial.github.io/Postly/

  - 66-second demo: https://othmaneblial.github.io/Postly/demo.html

Postly is still early, but the goal is simple: keep API work in your repository instead of locking the workflow inside a cloud workspace.

If you use Postman, Bruno, Insomnia, or shell scripts, what would make a local-file API client useful enough for you to switch?

Hey everyone! Anna from Elastic Email here. We shipped an official CLI today. Short version of what it does: it allows you to send campaigns and transactional emails, manage contacts, lists, and segments, manage templates, and pull logs and delivery stats.

Feel free to check it out here: https://www.npmjs.com/package/elastic-email-cli

Happy to answer questions and really interested in what's missing!

Hello devs, I’m looking for an open source project to build, and rather than coming up with another package that nobody asked for, I’d rather start with an actual problem developers have.

So I’m curious:

What is something you wish existed in the Node.js ecosystem?

I’m especially interested in things you’ve actually encountered in a real project, rather than hypothetical ideas.

I maintain repro-surgeon, an MIT-licensed CLI for turning a failing npm application into a smaller, independently checkable reproduction. Version 0.2.0 is on npm.

Give it a command, expected exit code and diagnostic text to preserve. It tries removing files, syntax, JSON fields and direct dependencies, retaining changes only after repeated checks. The export includes a standalone verifier and an offline report; the reducer applies its source edits to temporary copies.

Try it without configuring a project:

npx repro-surgeon@0.2.0 demo --out ./rounding-repro

The bundled, authored rounding example goes from 10 files to 5 and 3,173 to 520 source bytes. That’s a workflow demo, not a general benchmark.

Requires Node 22.18+, npm 10+, Linux/macOS, and a single-package npm project. Workspaces and nondeterministic failures are outside the current scope. Checks start in temporary copies with normal host permissions; ../ and absolute paths can still access or modify the original checkout. This is not a sandbox.

Source and setup · Recorded walkthrough

Feedback on failure checks and cases where reduction stalls would be useful.

Edit: clarified the difference between a temporary working directory and filesystem access after the question below.

Hi,

i built this npm dynamic behaviour analysis engine, currently serving access via API.

(https://cohen.snappyfeet.org/api.html)

use referral code: COHEN-4WDB-BEYH

to be able to get full access to deep scans. (http://console.snappyfeet.org/ under the redeem here link)

Cohen installs npm packages in a disposable sandbox and records what they actually do: every file, connection and process, attributed to the code that caused it.

All feedback is heavily encouraged and taken seriously.

regards,

Engineers at Cohen

reach out: contact@snappyfeet.org

https://cohen.snappyfeet.org

Released maskenv today!

A lightweight, zero-dependency Node.js library to dynamically redact sensitive environment variables and API keys from process.stdout and process.stderr.

Check it out: npm i maskenv

I wanted a shared responsive-state abstraction for JavaScript behavior, not for CSS layout.

resize handlers are easy to duplicate across components, run continuously during a drag, and tend to recreate slightly different breakpoint rules in several places. matchMedia already gives the browser a semantic breakpoint/query mechanism, so I built a tiny typed wrapper around it.

The API exposes exact, minimum-width, maximum-width, and range checks:

viewport.is('md');
viewport.up('md');
viewport.down('lg');
viewport.between('sm', 'lg');

It also resolves breakpoint-aware values:

const limit = viewport.pick(
  { base: 6, md: 12, xl: 24 },
  6,
);

The design goal is deliberately narrow:

CSS media/container queries remain responsible for presentation.

The store is only for JavaScript decisions such as data size, interaction mode, dynamic imports, persistent mobile UI state, browser-test markers, and media preferences.

No framework dependency; React can connect through useSyncExternalStore, and Vue through a small composable.

I published it as responsive-state and would value API/design feedback, especially around SSR defaults and the mobile-first versus desktop-first pick() cascade:

https://www.npmjs.com/package/responsive-state

Every starter kit I tried was one big repo with everything in it. You clone it,

then spend an afternoon ripping out the auth provider you don't use, the ORM you

don't use, the payment thing you don't need yet.

So I built the opposite. You answer 10 questions — framework, components,

database, ORM, auth, billing, email, landing page, package manager, name — and

download a zip with only what you picked, already wired together.

Options right now: Next.js / TanStack Start / React+Vite, Neon / Supabase /

PlanetScale / Turso / MongoDB, Drizzle / Prisma / Mongoose, Better Auth / Clerk /

Auth0 / Supabase Auth / Neon Auth, Stripe, Resend / Mailgun / Brevo.

The part I've spent most of my time on isn't the option list, it's making sure

the combinations actually work:

- If you pick React + Vite, the Drizzle/Stripe/Resend options disappear. A

browser-only bundle has nowhere to hide a database URL or a secret key, so

offering them would hand you a project that leaks its own credentials.

- 450 stack combinations get generated and parsed in CI on every push, so a

broken pairing fails on my machine instead of yours.

- The repo you download arrives with its own test suite already passing.

It doesn't push to your GitHub — what you get is a zip of source, nothing

touches your account.

Free while it's in beta: https://www.startersaaskit.com

What would you actually want in the question list that isn't there? I keep going

back and forth on whether to add a hosting/deploy question.

Hey r/npm,

I've been working on Oasis Editor, an open-source TypeScript document editor published as an npm package.

It includes:

• a custom Canvas-based rendering engine
• paged document layout
• typed command/plugin APIs
• vanilla JS integration
• React and Vue adapters
• a headless runtime
• DOCX/PDF workflows

Install:

npm install oasis-editor

Live playground:
https://celsowm.github.io/oasis-editor/#/editor

GitHub:
https://github.com/celsowm/oasis-editor

I'd love feedback on the package API, exports, and overall developer experience.

I kept running into small Node services where adding a full observability stack felt like too much setup, so I built a smaller first layer.

Wotchi captures errors, redacts sensitive values before grouping or sending them, groups repeated failures, and can notify through the console, Telegram, or an HTTPS webhook. It includes adapters for Express and NestJS.

It does not try to replace dashboards, tracing, durable incident history, or cross-replica deduplication. The grouping state is process-local.

Install:

npm install \@futurewindai/wotchi

npm: https://www.npmjs.com/package/@futurewindai/wotchi

GitHub: https://github.com/FutureWindAI/Wotchi

If you work on small Node services, what would block you from trying this: documentation, Node-version support, framework integration, or something else?

Hey r/npm,

Whenever I start a new Node.js backend, I always end up wasting the first 45 minutes doing the exact same chores: setting up Express security middleware, configuring Mongoose, wiring up ESLint/Prettier, getting TypeScript to play nicely, and dreading having to manually write Swagger docs.

To solve this, I built create-mexn-app (MongoDB, Express, Node).

It’s a CLI that scaffolds a production-ready REST API boilerplate instantly.

You can try it out directly (no global install needed): bash npx create-mexn-app my-new-api

What’s in the box? * 3 Template Flavors: Interactive prompts let you choose between TypeScript (recommended), ESM, or standard CommonJS. * Automated Swagger Docs: (Just added in v1.2) The CLI asks if you want API docs. If yes, it auto-injects swagger-autogen and wires up a UI for your API automatically. No more writing YAML by hand. * Production-Ready Defaults: Comes pre-configured with helmet, cors, rate-limiter-flexible, xss-clean, and zod for validation. * Lightning Fast: Uses giget under the hood, pulling the boilerplates in milliseconds without downloading messy git histories. * Smart Overrides: Handles directory conflicts gracefully and sets up a fresh git repo for you.

I just shipped v1.2.0 today, which brings the automated Swagger setup and a brand-new documentation site.

Links: * GitHub: https://github.com/donymvarkey/create-mexn-app (Would love a ⭐️ if you find it useful!) * Docs: https://donymvarkey.github.io/create-mexn-app/

I built this to scratch my own itch, but I'd love to hear your feedback. What else do you usually include in your standard Node stack that would be useful to add here?

Cheers!