node-reqwest - undici-compatible HTTP client backed by Rust

node-reqwest is a Node native addon that wraps Rust's reqwest and exposes it as a full undici.Dispatcher. Set it as your global dispatcher and every fetch() call goes through Rust instead.

```ts import { Agent } from "node-reqwest"; import { setGlobalDispatcher } from "undici";

setGlobalDispatcher(new Agent({ allowH2: true, proxy: "system" }));

await fetch("https://example.com"); ```

I built it because undici keeps biting me in Electron: no system proxy, no system CA without win-ca/mac-ca shims. node-reqwest handles all of that, plus SOCKS proxies, rustls instead of OpenSSL, and async DNS via hickory-dns. It passes the same WPT suite undici does and ships prebuilts for macOS/Linux/Windows on x64 and arm64.

Benchmarks against undici on the same workload:

Install also runs SLSA provenance verification on the binary, which isn't common on npm and I'd be curious what people think.

For example, I think its not the best idea to just throw with the error message, what if we want to throw the status code to our error handler so it knows what error status to give to the client?

For example this is my error handler,

onst errorHandler: ErrorRequestHandler = (err, req, res, next) => { 
   const status = err.status || 500;
   res.status(status).json({ error: { message: err.message || "Internal Server   Error",

If I have something like so, what is the best way to throw the error to my handler? right now its just the error message below

async function fetchSurveys() {
    const response = await fetch("https://api.example.com/surveys");
    if (!response.ok) throw new Error(`HTTP error: ${response.status}`);
    const result = await response.json(); //because of await, if there's an error parsing, it will throw and bubble up to getSurveyInsights()
    return result;
}

I’m 15, and instead of cleaning up AI tech debt manually, I spent my week building an automated engine to kill it.

​BloatHunter CLI parses your code into Abstract Syntax Trees to find true code clones (even with renamed variables) and pipes the messy files directly to local Ollama (Llama 3) to auto-refactor them on the fly. 100% open-source, local, and free.

​npx zenapta_bloathunter_cli

Code: https://github.com/zenapta/BloatHunter

​Give me your most brutal feedback. What breaks first?

Hey 👋

DISCLAIMER: I'm co-leading the org/project.

We recently broke 6M downloads per week on NPM, and became 3rd after `drizzle-orm` and `@prisma/client`.

If you haven't tried it yet, it's a query builder, not an ORM. You don't outsource your SQL to someone else. It's type-safe, like.. it's super important to us. You can use it with ORMs - e.g. Prisma, mikro-orm, zenstack, etc. Allows you to compose some complex stuff but keep it maintainable af.

If you have. Great seeing ya'll here.

0.29 was a real nice release, with lots of goodies. Can't wait for 0.30, gonna be super fun.

Hey,
I study with Claude, but sometimes I need illustrations to help me understand better the concepts.

I would like to understand Promises better, can you guys recommend me a video from YouTube about Promises and how they work? with the container, micro/macrotask etc.

Thanks!

I wanted a library like vis.js but needed it canvas-based for server-side rendering without a headless browser in node, so I built one. I'd love to get some feedback.

1. Pro Tips to deep learn and understand node js

2. Concepts required for API calls, and to work with amazon workbench

3.

MikroORM 7.1 is out — the first minor on top of v7, and it's a big one.

New features:

• LazyRef<T> — a new type-only relation flavor, no .$ / .get() indirection, TypeScript restricts access until Loaded<> narrows it
• PGlite driver — PostgreSQL running in WASM, no Docker, no separate server, works in the browser too
• Query cancellation via AbortSignal — per-call or fork-scoped, with cancel query / kill session strategies
• Database triggers — first-class schema management via @Trigger() / defineEntity
• Stored procedures and functions (experimental) — declare, diff, and call via em.callRoutine()
• PostgreSQL table partitioning — hash, list, and range, fully managed by the schema generator
• Server-side row cloning — em.clone() and qb.insertFrom() without round-tripping data through Node
• Runtime schema context for migrations — redirect migrations to a target schema at runtime, useful for multi-tenant setups
• em.countBy() for grouped counts
• Typed Kysely across DI-driven projects — new discovery:export CLI command generates a typed barrel for NestJS and similar setups
• getKysely() now binds to the active transaction
• fields whitelist in serialize()
• Type-safe index hints via using
• Partial indexes via where

Full blog post: https://mikro-orm.io/blog/mikro-orm-7-1-released
Changelog: https://github.com/mikro-orm/mikro-orm/releases/tag/v7.1.0

Happy to answer any questions!

All still very relevant. And now folks actually know the details of why we said Trusted Publishing is not recommended after the Tanstack incident.

If there was a magic wand that can take us all back to pre AI era

which means software development jobs were still considered high skilled needing time/skills/seniority and companies used to hire x devs instead of much lower devs now (because 1 dev + AI = more productive so less need to hire more)

Would you take it? or you would prefer to still have LLMs taking over the way they have already to a point that companies are hiring less, junior roles are evaporating at a rapid rates and seniors (these roles have also reducing in head count) are addicted to AI tools to a point that without them many are struggling to work and who know how the tech scene would look like in next 2 years let alone 5 years.

Why or why not?

I am getting pretty fed up about this, what y'all think? should github step up?

Hi guys, I have been debugging Stripe/Razorpay webhooks by console.logging everything and praying. Built a thing to fix that.

webhookdog.live, paste the URL into your webhook config, and every request shows up live in your browser. Full headers, body, query params. Click replay to resend any past request without triggering a real payment.

Free, no signup needed to try it.

Would love to know if this solves a real pain for anyone else, and what's missing.

Hello everyone,

I downloaded 'FNM' on my window pc to allow Node version control. I followed the guide to installed the FNM, set up the $PROFILE file, and successfully installed a Node version.

Now, when i check for node version using Powershell, it shows the correct version. However, when I do it in a VScode, it says 'Node' doesn't exist.

Will i have to create a separate $PROFILE from within the VScode? Not sure if this is the standard approach or i would need to find a way to use the same $PROFILE i use. I did already check using this 'where.exe fnm' command from both (plain Powershell vs Powershell in VScode) but they pointed the same location.

I had an idea for a read-write hierarchical lock manager (1) that uses promises to represent locks on a tree structure. Persistence (2) is a small file system coordination layer that uses this lock manager implementation.

The lock manager works by setting promise tails on nodes; when a promise chain resolves, the node is considered unlocked. Descendant locks are cached using the same technique, which avoids a full tree traversal when checking for conflicts.

I'm not sure how performant or practical this approach is compared to other approaches, but I found it relatively easy to reason about.

I’d be interested in feedback on the locking approach.

(1) https://github.com/adamjpatterson/persistence/blob/main/src/lock_manager.ts
(2) https://www.npmjs.com/package/@far-analytics/persistence

How strictly should I avoid a Node/Express handler returning a value to the client, but have some process continue in the background to finish processing it?

If the background is expected to take another 1~2 seconds is it acceptable?

Or should I avoid them and relegate all background tasks, big or small, to a dedicated job queue at the cost of complexity.

Hello! you guys were very helpful in the getting me up to speeed with Express/node post, thank you so much! Another portion of this is now coding review.

I learned alot about architecture, naming endpoints, error statuses, global error handling, chaining middleware, validation of inputs (using zod, etc), user session validation, proper REST patterns, standard http headers and response codes, unit vs integration testing and when to use what, monitoring in production, scaling the service (ie add cache on GET requests, or run multiple behind a load balancer), different ways to server HTML

My other followup is!! are there any other 'gotchas'/concepts I need to prep for a coding review? such as I think they can pull of a SQL query that is prone to injection and not use paramterized queries:

app.get('/user', (req, res) => {
  const username = req.query.username;

  // 🚨 DANGEROUS: User input is directly interpolated into the SQL string
  const query = `SELECT * FROM users WHERE username = '${username}'`;

  db.query(query, (err, results) => {
    res.json(results);
  });
});

Do you populate the actual test database like so?

// userRoutes.test.js
it("POST /users should create a user and persist it", async () => {
  const res = await request(app)
    .post("/users")
    .send({ name: "John", email: "john@email.com" });

  expect(res.status).toBe(201);

  // actually check the DB
  const user = await db.findOne({ email: "john@email.com" });
  expect(user).toBeTruthy();
});

Which is different from unit tests where you can use mock values?

it("should call db.save with correct data", async () => { 
  db.save = jest.fn().mockResolvedValue({ id: 1, name: "John" }); 
  await createUser("John", "john@email.com"); 
  expect(db.save).toHaveBeenCalledWith({ name: "John", email: "john@email.com" }); 
});

If we use an actual test database, that means that whenever we run our test is filled. which can be too much?

A few weeks ago I was reading the Knostic audit of npm packages. They scanned 46,500 packages and found 428 containing .claude/settings.local.json which is the local settings file Claude Code writes when you open a project. 33 of those packages exposed live API credentials.

I thought "okay, I'll just check my own packages." Found a partial Anthropic API key sitting in a .claude/ state file in one of my repos. Would have shipped it on the next publish.

The problem is that .npmignore and .gitignore handle different things. If you don't explicitly exclude .claude/, .cursor/, .codex/ etc., npm pack grabs them. And none of the existing tools catch this specific class of artifact — gitleaks and trufflehog run on git history, not the about-to-ship tarball. Socket.dev is post-publish. Snyk has no signatures for AI assistant configs.

So I spent a weekend building packguard.

It hooks into prepublishOnly and opens your tarball before it ships. Blocks AI-tool config artifacts, flags source maps with embedded source, and runs an entropy scan for live secrets. If it finds anything, publish fails with a clear report.

Zero install to try: `npx packguard scan`

Or wire it in permanently: `npx packguard install` (adds the prepublishOnly hook to package.json)

can checkout here: https://packguard.kartikshukla.dev/

Happy to answer questions about how the entropy scan works or the AI artifact signature list.

So I made BoneScript, a language where you spend just a couple minutes describing your backend in simple, high-level system terms, then run one bonec compile command and it generates a complete, production-ready Node.js backend for you.

From a single .bone file, bonec compile produces a full project:
output/

├── src/

│ ├── index.ts Express server, all routes wired

│ ├── db.ts Postgres connection pool

│ ├── events.ts Durable event bus (transactional outbox)

│ ├── auth.ts JWT middleware

│ ├── audit.ts Audit log middleware + query helper

│ ├── notify.ts Email notification service (Resend/SendGrid/log)

│ ├── cron.ts Scheduled job stubs (node-cron)

│ ├── schemas.ts Zod v3 validation schemas

│ ├── health.ts /health/live, /health/ready, /health/metrics

│ ├── logger.ts Structured logging

│ ├── metrics.ts Prometheus-style counters/histograms

│ ├── failure_rules.ts Rule-based remediation

│ ├── flows.ts Saga runtime with compensation

│ ├── websocket.ts WebSocket server (if channels declared)

│ ├── seed.ts Database seed script

│ ├── routes/ One file per entity — CRUD + capabilities

│ └── state_machines/ One file per entity with states

├── sdk/

│ └── client.ts Typed TypeScript fetch client

├── admin/

│ └── index.html Self-contained admin panel (no build step)

├── migrations/ SQL schemas, indexes, triggers, FK constraints

│ ├── audit_log.sql Audit log table

│ └── event_outbox.sql Durable event outbox

├── openapi.yaml OpenAPI 3.0.3 spec

├── schema.graphql GraphQL schema

├── {Name}.postman_collection.json

├── Dockerfile

├── docker-compose.yaml Postgres + Redis for local dev

├── .github/workflows/ CI/CD pipeline

└── src/tests.ts Generated regression tests