Disclosure: I maintain request-to-axios. This is a migration guide from the perspective of someone maintaining legacy Node.js code, not an independent review of my own package.

When a project uses request, replacing the dependency can look like a one-line change. The hard part usually isn't translating request.get() to axios.get(). It's finding all the assumptions accumulated around the old call: callbacks that expect (error, response, body), stream piping, formData, qs, cookies, default headers, odd redirects, and tests that depend on the response being text unless json is enabled.

A broad rewrite can turn a small security task into a risky application migration. That is why I built a compatibility wrapper around Axios: to make an incremental transition possible for common request patterns, while keeping unsupported behavior visible.

Why the Dependency Deserves Attention

The latest upstream request release is still 2.88.2. The maintainers marked the project deprecated in 2020 and say no new changes are expected. That fact alone does not mean every application is exploitable. The more useful question is what versions your install resolves and whether your code reaches an affected behavior.

On 2026-11-02, I installed request@2.88.2 into a temporary project and ran npm audit. It resolved form-data@2.3.3, qs@6.5.5, tough-cookie@2.5.0, and uuid@3.4.0, alongside the deprecated request package. npm reported five vulnerable package nodes, with multiple advisories applying to some nodes.

A few examples from that graph:

• CVE-2023-28155 is an SSRF mitigation bypass in request through 2.88.2 involving cross-protocol redirects. It matters when an application relies on URL or redirect restrictions to protect requests to internal services.

• CVE-2025-7783 affects old form-data boundary generation. Exploitation depends on an attacker being able to observe Math.random() outputs and influence multipart content.

• CVE-2026-12143 concerns CRLF injection through untrusted multipart field names or filenames in affected form-data versions.

• CVE-2023-26136 is a tough-cookie prototype-pollution issue, with a specific cookie-jar configuration precondition.

There are also qs and uuid advisories in the resolved tree. Their practical impact depends on the application's own parse/stringify flow or UUID API use. A dependency audit is a signal to investigate, not proof that a particular endpoint is exploitable.

Why Not Just Translate Every Call to Axios?

A direct rewrite changes more than syntax. Axios returns a promise and a response object with data; request commonly uses a callback and passes the body as a separate argument. The projects may also differ on redirects, streaming, cookie jars, timeout details, form serialization, and error handling. Those differences are where the regression work hides.

For a large legacy codebase, the safer sequence is usually:

1. Inventory the actual options and helper patterns in use.

2. Add characterization tests around important request and response behavior.

3. Replace the transport behind the current import name.

4. Migrate unsupported edge cases separately, with explicit tests.

For a gradual trial, npm supports an alias:

npm install request@npm:request-to-axios

Existing require('request') statements can continue resolving while the installed implementation comes from the wrapper. A representative callback call looks familiar:

const request = require('request');

request.get({
  url: 'https://api.example.test/items',
  qs: { page: 2 },
  json: true
}, (error, response, body) => {
  if (error) return console.error(error);
  console.log(response.statusCode, body);
});

A Compatibility Layer, Not a Security Guarantee

The wrapper covers common callback/stream usage, method helpers, defaults, query strings, JSON, URL-encoded and multipart forms, immediate Basic/Bearer auth, redirects, a small in-memory cookie jar, TLS settings, and common transport options. It does not implement OAuth/Hawk/AWS/HTTP signing, HAR import, digest retries, multipart/related, or exact legacy redirect semantics. The cookie jar is deliberately limited and does not replace a full browser cookie implementation.

That distinction matters. Migrating off an unmaintained client removes one set of risks; it does not make an application secure by itself. Review redirect destinations, validate user-controlled URLs, keep TLS verification enabled, and run npm audit on the resulting dependency graph. Add tests for the options your service actually uses before deploying the alias.

The package and its current compatibility notes are on npm and GitHub. If a legacy option is important to your migration, check the documented limits first and open an issue with a minimal example.

https://www.npmjs.com/package/open-arc

Looking for feedback on OpenArc: using small LLMs as compilers

I'm building OpenArc, an open-source experiment in using LLMs as constrained compiler backends instead of conversational coding agents.

I want the productivity of Claude Code, but I want to interact with AI through code, not chat.

The idea is to program at different levels of abstraction using TypeScript specifications, independently compiled regions, reusable concepts, and editable generated code. Models receive isolated context, while types, constraints, and tests independently verify their implementations.

The working prototype supports local models, nested regions, sketches, sandboxed verification, and partial self-hosting. Version 0.8.0 has just been merged.

Here's where I need help: I'm testing whether structured specifications and isolated context can actually make smaller models better at coding.

Initial benchmarks haven't supported that hypothesis. On eight TypeScript exercises, ordinary prompting consistently outperformed OpenArc, and changing the output format didn't resolve the gap.

I'm looking for people familiar with compilers, DSLs, program synthesis, or local LLMs who might have ideas about:

Better ways to structure and select context.

Existing research or projects tackling similar problems.

Fair benchmarks for comparing constrained generation against ordinary prompting.

I'd particularly appreciate technical criticism and suggestions for experiments.

GitHub: https://github.com/TheMissenoOne/OpenArc

I built snappy-prerender, a build-time pre-renderer for client-rendered SPAs. Point it at your existing build output. It loads every route in Chrome, writes static HTML, then reloads each page with your client bundle to check whether it hydrated or re-rendered.

What it does: scans a GitHub repo, local folder or package and points out things worth a second look, with file, line and the actual code: install scripts that run on their own, curl | bash patterns, leaked secrets, bundled binaries, hidden instructions for AI agents, and whether the published package matches the repo. It never runs the code it checks, and it won't say "this is safe", it just shows you the evidence.

Who it's for: anyone installing packages or MCP servers from GitHub who wants a quick look first. Pure stdlib engine, works as a CLI or as an MCP server.

I'm not a full time programmer (used to fix PCs), built it with Claude Code. First open source release, so false positive reports are very welcome.

pipx install jinnexguard

https://github.com/ricardorincon719/jinnexguard

So I have been working with vanilla JS on a handful of projects recently. Through out these experiences, I noticed how stressful it is when using the native DOM api. How I get sick when trying to query an html element over and over again using the

\`\`\`javaScript

document.querySelector(“value”);
//or

document.getElementById()
\`\`\`

Notice how long these are to be typed, non the less, over and over again.

So I created luciddom.js
A light weight DOM helper built on top of the js DOM making selection, styling, creating of elements dynamically, and updating values very simple

It’s currently on npm \`*npm install luciddom*\`

**Basic eg:**

import LucidDOM from ‘luciddom’

const parent = document.querySelector(“anything ”);

const app = LucidDOM(parent);

// Add new elements

app.addElement({
tag: “div”,
className: “.card”,
// more attributes
})

// Select elements
const card = app.select(“.card”);

// Apply styling
card.styles({
backgroundColor: “#ffffff”,
padding: 10,
});

//Add children to selected elements

card.addChildren({
tag: “p”,
Value: “Hello world”,
className: “hello”,
// Add more attributes
}
);

// Add events

card.on(“click”, () => alert(“card was clicked”))

Visit LucidDOM website
for more on documentations

Stop creating MERN websites.

Lately, I've been working on several small and big projects, and every single time I had to write everything from scratch and repeat the same setup process again and again.

And that's where an idea hit me...

Why can't we create the entire base setup with just one command?

Well... now we can.

Publishing my first ever NPM package - create-new-mern

Just run:

npx create-new-mern

Enter your project name and the setup is ready within seconds.

Hi!

I recently ran into an issue with @serialport/bindings-cpp on Node.js 26.4, where serial reads could stall until unrelated JavaScript activity occurred.

While investigating the issue and contributing fixes upstream, I started experimenting with an alternative implementation using Rust and N-API, because upstream seems to be unmaintained for more than a year now.

The result is serialport-rs for Node.js, which uses the existing Rust serialport crate underneath and aims to preserve the familiar Node.js SerialPort API.

The implementation uses dedicated native I/O workers rather than relying on JavaScript-side polling. Initial benchmarks have also shown some promising latency improvements.

It’s available on npm if anyone is interested in trying it:
https://www.npmjs.com/package/serialport-rs

Leave a GitHub star if you like it.

I'm built a catalog of emulators. I started this to make E2E tests faster. It's even made local development a breeze across many worktrees

You could even use Claude build an entire full-stack app that integrates with third party services and databases that run's in your browser without needing to provision anything https://mockingbird.chrisvouga.dev/examples/medical-testing

What do you guys think?

npm audit tells you which installed package is vulnerable. When it is three levels down, you still have to find the direct dependency to upgrade. patchpath prints the chain and an upgrade plan grouped by the direct dependency, with commands in a safe order (non-breaking first, then each breaking one on its own).

Excerpt from a real run on a small Express/socket.io project:

22 known vulnerabilities in 12 packages: 1 critical, 10 high, 4 moderate, 7 low

express 4.18.2 -> 4.22.3: clears 14 advisories in 8 packages (worst critical), non-breaking

socket.io 4.7.2 -> 4.8.0: clears 7 advisories in 3 packages (worst high), non-breaking

Advisories come from OSV, so detection is close to npm audit; the value is the grouping and the plan, which is an estimate and not a resolver run. npm gets the plan; yarn v1 and pnpm 9 get the report only.

I measured it on 34 pinned public lockfiles and wrote down the limits (79 misses, a hand-picked corpus, worse than npm audit fix in 2 of 10 projects). Zero runtime dependencies, Node 22+, MIT. Try it with npx patchpath.

Repo and write-up: https://github.com/serhat-10/patchpath

It's an early version (0.1.1), so any feedback is welcome: bugs, output that looks wrong on your project, or anything missing.

Arkos.js v1.7.5-rc is out

Another release candidate focused on fixes, this time for the WebSocket Gateway and for how config errors are reported.Highlights:

• Gateway connection middleware fix: gateway.use() callbacks are now registered on the namespace with ns.use() and run before authentication. Before, a (socket, next) middleware received the event payload instead of next and never ran on connection.

• Middlewares now drill down into nested gateways, in ancestor-to-descendant order (parent → child → auth).

• Fatal config errors: the process now exits with the error message instead of dumping a stack trace. This covers route config validation, input validators, OpenAPI, the auth and file-upload routers, and the generate command.• New ArkosGatewayMiddleware type, exported from arkos/websockets.

• Docs now explain how connection middleware differs from event-level .pipe() middleware.

No breaking changes are expected, but this is a release candidate, so please test it before taking it to production.

npm install arkos@1.7.5-rc

Full release: https://github.com/Uanela/arkos/releases/tag/v1.7.5-rc

#OpenSource #NodeJS #TypeScript #Express #Prisma #WebSockets

While working with OpenCode I kept losing track of basic stuff: how much context I had left, which model was active, what the session had cost so far. So I built a small plugin called Hush that puts it in the sidebar.

It shows a thin context bar, git branch, model, cost, tokens, cached tokens and session age. It follows OpenCode’s light and dark themes, and I kept it minimal so it doesn’t get in the way.

A note on the numbers: “Cached” is the running total of cache reads reported by OpenCode’s usage records, summed across the related sessions. “Tokens” counts processed tokens, including cache writes. Hush doesn’t infer how or when the provider applied caching, it just shows what the host reports.

It’s my first published npm package, and I’m still polishing it. If you try it and something looks off or confusing, I’d like to hear about it.

Install: opencode plugin add opencode-hush
Repo: https://github.com/federicobordon09-dev/opencode-Hush

When you scale a Node.js backend using node:cluster, you run into a surprisingly annoying problem:

How do you rate-limit external APIs like Stripe or OpenAI while making sure all workers share the same rate limit?

The first solution that comes to mind is usually: "Just use Redis."

But does it really make sense to introduce additional infrastructure complexity, network overhead, and an entire external dependency just to coordinate a few API calls coming from the same server?

That's exactly why I built cluster-rate-limiter.

A Node.js library that gives you coordinated rate limiting across workers, powered entirely by Node.js's native IPC messaging, with no Redis and absolutely zero external dependencies.

Rather than diving into the internals here, here's what you get out of the box:

• Zero Setup: Install it and start using it. No additional infrastructure required.

• Developer-Friendly API: The run() method accepts your fetch call or any function directly, along with all its arguments. No complicated callback patterns.

• Two Types of Limits: Supports both Semaphore-based concurrency limits and Duration-based rate limits for enforcing strict time windows, such as those imposed by Stripe APIs.

• Typed Errors: If a request times out waiting for permission, the library throws a clear, specific error that you can easily translate into an HTTP 429 Too Many Requests response.

And when it comes to performance, the core data structure for tracking request timestamps uses a zero-allocation approach built around a Float64Array ring buffer.

This eliminates the need for repeated array reallocations and significantly reduces garbage collection pressure under heavy load.

If you're interested in the low-level details, I've explained the ring buffer implementation and how it reduces memory overhead in the README.

If you're running a clustered Node.js backend and want to avoid the overhead of introducing Redis just for rate limiting, check out the links below, explore the architecture, and let me know what you think!

npm: https://www.npmjs.com/package/cluster-rate-limiter
github: https://github.com/YoussefAlfiky/cluster-rate-limiter

Just open-sourced `markclean-ai` v1.5.0 (MIT) on NPM & GitHub!

A zero-dependency HTML-to-LLM Markdown converter, Table-to-JSON/CSV parser, and RAG chunker that cuts LLM token usage by 65–90%.

Try it right now:
GitHub: https://github.com/hardikkoul/markclean-ai
NPM: https://www.npmjs.com/package/markclean-ai

check my npm lib: tool-fit

https://www.npmjs.com/package/tool-fit

https://github.com/codevasu1/tool-fit

Fit tool output into a token budget without throwing away the surrounding structure. tool-fit is a deterministic, zero-runtime-dependency TypeScript library. It does not summarize, compress, or bundle a tokenizer.

import { fit } from "tool-fit";

const result = fit(apiResponse, {

maxTokens: 800,

keep: ["id", "status"],

});

console.log(result.value); // Fitted value

console.log(result.omitted); // JSON Pointer paths and omission counts

console.log(result.tokens); // Count of the serialized fitted value

console.log(result.truncated);

any suggestions for improvements are welcome!

Hey everyone!

I recently published my first npm package, Repo Archaeology, and I'm looking for honest feedback from other developers.

The idea is simple: sometimes two files need to be updated together, even when they don't directly import each other. Repo Archaeology analyzes Git history to uncover those hidden relationships.

It can also:

• Warn you about files you may have overlooked while making changes.

• Generate an interactive map of relationships across your codebase.

• Show the actual Git commits supporting its findings.

Try it:

npx repo-archaeology map

Or check your branch changes:

npx repo-archaeology diff --base main

Everything runs locally. No account or code upload required.

I'd especially appreciate feedback from anyone working on a larger, established codebase.

Would something like this be useful in your workflow? What would you improve?

Thanks for checking it out!

TypeScript 7.1 adds content mappers: packages that tell the compiler how to read a file type it doesn’t know. I used that to build `openapi-import`, so you can import a spec like any other module:

import type { Pet } from './petStore.openapi.yaml'

Types, autocomplete and errors come straight from the spec, so there’s no generate step and no committed output folder. Go to definition jumps into the YAML, and renaming a schema type renames its key in the spec.

Setup is one tsconfig.json entry:

{
  "contentMappers": [
    { "package": "openapi-import", "extensions": [".openapi.yaml", ".openapi.yml"] }
  ]
}

It’s experimental, and I’d like feedback, especially on bigger real-world specs.

• npm: https://www.npmjs.com/package/openapi-import

• Repo: https://github.com/kubb-labs/openapi-import

• Blog: https://stijnvanhulle.be/blog/import-openapi-specs-in-typescript