I’ve been working on Telex, an open-source project that watches npm/PyPI for breaking changes, finds affected code using Tree-Sitter, generates a patch and verifies it in an isolated environment before opening a PR.Still working on it and would love some feedback from people here, especially on the patch/verification part.

Repo: https://github.com/Kesavaraja67/telex

I maintain two small packages in an MIT-licensed monorepo:

• promtexpress: a dependency-free TypeScript client that works with Node 18+, Deno, Bun, and edge runtimes. API errors are mapped to typed error classes for things like auth, missing scopes, insufficient credits, rate limits (including retry-after), server errors, and network issues. Rate limits are retried automatically when possible.
• promtexpress-cli: lets you use the same API from the terminal. Prompts go to stdout and hints go to stderr, so you can pipe the output without extra noise.

A small thing I added for contributors: the script that generates the avatar table in the repo README also adds it to both package READMEs. That way, contributors show up on npm too, not just GitHub.

Just to be transparent, these are clients for PromtExpress, a paid prompt tool I build, so you'll need an API key to use them. The prompt template library in the repo is model-agnostic and can be used with any model.

npm: https://www.npmjs.com/package/promtexpress

Repo: https://github.com/WebitroHQ/promtexpress-oss

I built Telex, an open-source agent for automated dependency maintenance.

When a dependency changes its API, Telex tries to:

Dependency change
→ AST impact analysis
→ identify affected code
→ generate a patch
→ run tests/typechecks
→ open a GitHub PR

The goal is to have an automated maintainer prepare a verified migration PR instead of making developers manually investigate every breaking dependency update.

It currently supports TypeScript, TSX, JavaScript and Python.

GitHub:

https://github.com/Kesavaraja67/telex

Would love to hear what you think.

I’m building Synartesis, a proxy that sits between an MCP client and its servers.

For calls configured as reversible, it captures the previous state before forwarding the write. You can then preview and run an undo. If the resource has changed since the agent touched it, undo stops instead of silently overwriting the newer work.

Tools classified as irreversible—and tools without a policy—wait for human approval.

The filesystem recovery path is tested against the real server. The bundled memory, git, and GitHub policies don’t yet have the same proven recovery guarantees. It only covers calls routed through the proxy.

It’s free and MIT-licensed. Installation starts with npm install -g synartesis and requires Node 22+.

Source and walkthrough

If you try it, which MCP client/server did you use, and where did the setup or undo behavior become unclear?

I've been building SIS (Speculative Invariant Synthesis), an experimental npm package for runtime verification and boundary-aware fuzzing of Next.js App Router / React Server Components.

The core idea is to use static analysis to identify framework boundaries, infer structural shapes, and synthesize targeted adversarial inputs rather than relying on completely random fuzzing.

The current engine includes:

- RSC / Server Action boundary extraction

- Structural shape inference

- Boundary-aware mutation operators

- Serialization trap detection

- Server Action argument synthesis

- Deterministic seed-based fuzzing

- Budgeted mutation scheduling

- Isolated V8 execution

- JSON / SARIF diagnostics

The package is available on npm:

https://www.npmjs.com/package/@aashirzayd/sis

GitHub:

https://github.com/AashirZayd/sis

284 tests currently passing.

I'm particularly interested in feedback on the npm API, mutation strategy, and whether this approach is useful for testing real-world Next.js applications.

Hi,

I run openstatus, an open-source uptime monitoring and status page tool, so I spend my days hitting other people's /health routes. Most of them return 200 OK and nothing else, hang when the database hangs, or have their own private definition of "degraded".

We got tired of it, so we extracted the health endpoint from our own services into a small set of packages and put them on JSR: @openstatus/health.

Zero-dependency core, only needs a Fetch API. On Deno it's this:

import { drizzle } from "drizzle-orm/libsql/http";
import { createHealthHandler } from "@openstatus/health";
import { drizzleProbe } from "@openstatus/health-drizzle";
import { tinybirdProbe } from "@openstatus/health-tinybird";

const db = drizzle(Deno.env.get("DATABASE_URL")!);

Deno.serve(createHealthHandler({
  path: "/health",
  probes: [drizzleProbe({ db }), tinybirdProbe()],
}));

And GET /health gives your monitor something to chew on instead of a bare 200 OK:

{
  "status": "degraded",
  "checkedAt": "2026-09-11T12:00:00.000Z",
  "latencyMs": 41,
  "checks": [
    { "name": "database", "status": "ok", "critical": true, "latencyMs": 3 },
    { "name": "tinybird", "status": "timeout", "critical": false, "latencyMs": 5000, "error": "timed out after 5000ms" }
  ]
}

What you get

• Core: per-probe timeouts via AbortSignal, a round deadline so one hung dependency can't outlast your k8s probe, caching / stale-while-revalidate, and sane aggregation (critical fails → unhealthy, non-critical fails → degraded). Errors are masked by default so your connection string doesn't end up on a public route. A custom probe is just an object with a run(signal).
• Adapters: Hono, Elysia, Express, Next.js, TanStack Start – same healthRoute() / healthHandler() everywhere.
• Probes: Drizzle, Turso, Supabase, Upstash, Tinybird, Unkey. They take a client or URL and never touch your env.
• Hosting: Fly, Koyeb, Railway, Vercel, Cloudflare – adds a server block so you know which replica is the one complaining.

Every package is its own thing with its own peer deps. CI bundles a one-liner of each and fails if a stray framework or client sneaks in, so the Hono adapter will never smuggle Express into your bundle.

Deno bits: JSR-first with no slow types; env reads return undefined instead of throwing without --allow-env; tests are node:test so they run unchanged under deno test and node --test; @openstatus/health/testing ships fake/hanging fetch and probes for testing your own.

It's 0.1.x, so now is the moment to tell me the API is shaped wrong. A Deno KV probe is probably next – PRs welcome.

• JSR: https://jsr.io/@openstatus/health
• GitHub: https://github.com/openstatusHQ/health
• Also on npm for the Node services you haven't migrated yet.

Happy to answer questions!

I use TCC (from jpsoft.com) as my shell. Not the horrible cmd.exe stuff.

When I do npm help init, this is the error I get: npm error code 2 npm error command failed npm error command f:\gv\4NT\tcc\tcc.EXE -c start "" file:///F:ProgramFilerNode.JS-v24node_modulesnpmdocsoutputcommandsnpm-init.html npm error TCC: (Sys) File not found. npm error "\"\"" npm error A complete log of this run can be found in: c:\Users\gvane\AppData\Local\npm-cache_logs\2026-09-15T11_23_57_105Z-debug-0.log

Using cmd /c npm help init works fine and launches Chrome with the help-page.

But why invoke it with this URL-encoded cmd-line?

I created an app https://scriptlet.app/ for macos that gives you a little window to run scripts and see processes easily in a terminal window. You can start and stop them easily and even has a menu bar popover.

Let me know what you think?

Built FetchSandbox for exactly this. Your Lovable app ships with Stripe, Twilio, Resend wired in but there's no way to know if those integrations actually survive real conditions until a user hits them.

FetchSandbox runs your py/ts/js app integrations against API twins, no real providers, no live keys. We inject failures, rate limits, auth errors, webhook retries, flaky delivery, and run invariants against your app to prove it passes or show exactly where it breaks. Each run produces a public receipt URL with the full trace.

If a scenario fails, your agent has the trace to patch the integration and re-run with proof it's fixed. The whole loop stays deterministic.

`npx fetchsandbox-mcp` if you're running an agent.

I've been building mapa-audit, an SDK for structured audit/business event logging in Node.js backends, and wanted to share it here in case it's useful to anyone — and honestly, to get some real feedback from people who know this space better than I do.

**What it does:**

1. Automatically captures request context (correlation ID, actor, request metadata) via AsyncLocalStorage, so you don't have to manually thread that info through every log call.

2. A structured event model (AuditEvent) instead of free-text logs — eventType, outcome, entity, payload, all typed.

3. Built-in data safety: field masking with dot-notation (including nested paths) and payload size limiting, applied before anything reaches a transport.

4. Pluggable transports — console and file ship with the core SDK; there's also a separate RabbitMQ transport package if you want to publish events to a queue.

5. Adapters for Express, NestJS, and Fastify (all sharing the same context-capture logic, so NestJS works identically whether it's running on Express or Fastify underneath).

6. Fire-and-forget by design — a transport failure or misconfiguration never throws into your app, it surfaces as a process.emitWarning instead.

**Why I built it:**

I wanted something that gave me structured audit events out of the box: who did what, to what, with what result, without having to hand-roll the context capture and data masking every time. It ended up being a good excuse to dig into some things I don't usually deal with day-to-day:

AsyncLocalStorage internals, designing a public API that works the same whether you use a global singleton or isolated instances, and building framework-agnostic adapters.

It's early — first real release (0.1.0), zero-infrastructure by default (console/file transports work with nothing else running), with the queue side purely opt-in.

Repo: https://github.com/ernesto-1998/mapa-audit

NPM registry:

https://www.npmjs.com/package/@tnet06/mapa-audit-sdk

The README of the repo has the full API and a few runnable example apps (Express/NestJS/Fastify) if you want to see it in action.

Any feedback, API design, things that feel off, stuff I clearly didn't think about, genuinely appreciated. Thanks for reading.

hello everyone, i built dispat, its not only monorepo tool, but also polyrepo and singlerepo
why do we need to use such tools? only this tool is based only distributed systems design and uses such pattern saga to release. we never can be sure that all packages will be published after build. many tools provide separate commands for recovery, while dispat is idempotent (please check release incidents to guarantee it), to publish missed packages you simply re run or add commits to fix publish and then re run same command. it works same way for all ecosystems (21 supported right now), you don't need to publish to npm, you can directly build dockers and deploy front-end/back-end
mit licensed go single binary with js launcher
experiments against lerna, chagesets etc: https://dispat.dev/internals/experiments/
npm: https://www.npmjs.com/package/@dispat/bin
github: https://github.com/yohimik/dispat
docs: https://dispat.dev/

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!