I’ve been building a small invoice reminder app after work. It had six users, including me, and was running as a Node app on serverspace cloud server.

One evening I noticed the memory usage slowly climbing. Restarting the app fixed it, but only for about half an hour.

I did what any tired developer would do and decided the infrastructure was the problem.

I added more ram.

The next morning, the memory was climbing again.

After going through the logs I finally found a setInterval() inside a function that ran whenever someone logged in. Every login started another background job to check for overdue invoices. None of the old ones ever stopped.

There wasn’t a sudden increase in users. There were just dozens of copies of my reminder job quietly running at the same time.

I moved the timer out of the login flow, restarted the app and returned the server to its original configuration. The memory graph has been almost completely flat since then.

The app didn’t need more ram. It needed me to stop creating immortal timers

Hey everyone,

PortFox 🦊 is a lightweight, open-source CLI that makes managing occupied ports simple.

No more manually searching for PIDs or figuring out which process is blocking your development server.

Features:

• Find which process is using a specific port
• List active TCP listening ports
• Safely terminate processes with confirmation
• Interactive terminal interface
• Find available ports
• JSON output for scripts and automation

Zero npm dependencies. Built with Node.js and supports macOS, Linux, and Windows.

Try it instantly:

npx portfox 3000

Or install it globally:

npm install -g portfox

 GitHub: https://github.com/merdanturan/portFox

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

MIT licensed and open to contributions.

Feedback, suggestions, and contributions are welcome!

Spent the last months building 3 drop-in JS widgets (forecast, dashboard, anomaly detection) that run 100% in the browser via WASM

These are framework-agnostic npm packages (React, Vue, Angular, or a plain custom element) that add time-series forecasting, an editable dashboard builder, and anomaly detection to any frontend app.

Everything runs client-side via WebAssembly, so no user data ever hits a server except a license check without a backend to deploy, no Python microservice.

Would genuinely love feedback from anyone who's had to build this kind of feature in-house.

https://datastripes.com/forecast-widget/

https://datastripes.com/dashboard-widget/

https://datastripes.com/anomaly-widget/

Mimic runs Node.js projects in a browser tab, similar to WebContainers but MIT-licensed and self-hosted. Programs run in Web Workers over an in-memory file system, real npm, pnpm and Yarn install from the registry, and a server's port becomes a URL you can load in an iframe.

It runs WASI Preview 1 executables as regular processes and implements node:wasi.

The playground has Vite, Angular, SvelteKit, Astro, Rspack and NestJS examples, and can open a public GitHub repo.

Repo: https://github.com/mimic-js/mimic

Any of us love the extensions, sure. A lot of us are real dev, somebody deeply, and obviously we love to share scripts and ideas, it's like a form of art for people like me.

Probably it is a silly idea but it is the same problem of supplies chain for dev software web and videogames for me, and I resolve with drastic solutions.

So...

If I could accept a "trust me bro" level for a simple idea, in something like agents, mail clients, calendars, note online (so, private data), debits cards... What are your parameters or checklist to understand "*ok, I have no problem with privacy about this extension*"?

Who really checks them? No one.

I think so... Do you have a personal checklist to make sure you've got them all ok?

I’m working on a personal project, so 0 users, and I have worked with SST in the past, but having to upgrade SST was a pain. Not sure if pulumi is any different of an experience, or is less painful and wanted insight on different experiences with either tool

Hey everyone,

I've been building a transaction-level firewall named Aegis//Agent to solve a critical issue: giving autonomous AI agents access to real money without risking catastrophic, runaway API loops or unchecked wallet drains.

The core architecture intercepts traffic, handles a micro-toll structure (currently configured at 1.00 KSh per task), and routes analytics straight to a live monitoring dashboard.

* Live Production Dashboard: https://aegis-agent-4u79.onrender.com (Note: Deployed on Render's free tier, so please give it about 50 seconds to spin up if it's currently sleeping!)

* Official GitHub SDK Repository: https://github.com

I just open-sourced the lightweight JavaScript SDK client file so other developers can test plugging their systems right into the compliance engine. I would love some brutal feedback from the developer community on the proxy architecture and the local M-Pesa/Crypto routing logic.

Check it out and let me know your thoughts!

I am currently building the email verification part of an express server but can't get the service to use a temporary email to send a mail. Following is the code and error. I am also using mailtrip.io for SMTP and used xeramail.com for the mail address to send from.

Now I don't know if I need mailtrip too on top of nodemailer or not but it provides the things I need to use such as usernamw and password.

import { createTransport } from "nodemailer";
import { log_nm_working, subjectBody } from "../strings.js";


// // Create a transporter using SMTP
// const transporter = createTransport({
//   host: "smtp.example.com",
//   port: 587,
//   secure: false, // use STARTTLS (upgrade connection to TLS after connecting)
//   auth: {
//     user: process.env.SMTP_USER,
//     pass: process.env.SMTP_PASS,
//   },
// });


// Todo Currently using the mail for testing puropses from mailtrap.io . It will change later on.
const transporter = createTransport({
  host: process.env.SMTP_HOST,
  port: Number(process.env.SMTP_PORT),
  secure: false, // use STARTTLS (upgrade connection to TLS after connecting)
  auth: {
    user: process.env.SMTP_FROM,
    pass: process.env.SMTP_PASS,
  },
});


export async function sendVerificationEmail(email, url) {
  try {
    await transporter.verify();
    console.log(log_nm_working);
    console.log(process.env.SMTP_FROM);
    console.log(process.env.SMTP_PASS);
    var { ver_body, ver_subject } = subjectBody(url);


    await transporter.sendMail({
      from: process.env.SMTP_FROM,
      to: email,
      subject: ver_subject,
      html: ver_body,
      text: `Verify your email: ${url}`,
    });
  } catch (err) {
    console.error("Verification failed:", err);
  }
}

Verification failed: Error: Invalid login: 535 5.7.0 Invalid credentials
    at SMTPConnection._formatError (file: ///home/app/servers/app/node_modules/nodemailer/dist/esm/smtp-connection/index.js:914:19)
    at SMTPConnection._actionAUTHComplete (file: ///home/app/servers/app/node_modules/nodemailer/dist/esm/smtp-connection/index.js:1758:34)
    at SMTPConnection.<anonymous> (file: ///home/app/servers/app/node_modules/nodemailer/dist/esm/smtp-connection/index.js:612:26)
    at SMTPConnection._processResponse (file: ///home/app/servers/app/node_modules/nodemailer/dist/esm/smtp-connection/index.js:1143:20)
    at SMTPConnection._onData (file: ///home/app/servers/app/node_modules/nodemailer/dist/esm/smtp-connection/index.js:859:14)
    at SMTPConnection._onSocketData (file: ///home/app/servers/app/node_modules/nodemailer/dist/esm/smtp-connection/index.js:178:44)
    at TLSSocket.emit (node:events: 509: 28)
    at addChunk (node:internal/streams/readable: 563: 12)
    at readableAddChunkPushByteMode (node:internal/streams/readable: 514: 3)
    at Readable.push (node:internal/streams/readable: 394: 5) {
  code: 'EAUTH',
  response: '535 5.7.0 Invalid credentials',
  responseCode: 535,
  command: 'AUTH PLAIN'
}

I needed a profanity check for usernames and chat. Like everyone else, I started by installing a filter from npm. Then I got curious and built a proper test set: about 6,500 swears in disguise (leetspeak, look-alike letters from other alphabets, zero-width characters, f.u.c.k with dots in it, full-width letters, and so on), plus 505 completely innocent texts that happen to contain a bad string.

I ran four packages on default settings, the way most of us actually use them.

| package | disguised swears caught | innocent texts blocked |

|---|---|---|

| leo-profanity | 1.1% | 8.7% |

| bad-words | 4.4% | 12.5% |

| @2toad/profanity | 4.4% | 11.5% |

| obscenity | 27.9% | 21.2% |

The interesting part is that there are two kinds of failure, and you can only pick one.

Whole-word lists (bad-words, leo-profanity, 2toad) look each word up in a list. Change one character and the word is gone. bad-words caught 3% of leetspeak, 1% of dotted spellings and 0% of full-width letters. `f.u.c.k` passes all four packages.

Substring matchers (obscenity) look inside words, so they catch a lot more. They also catch:

- Fukushima, Fukuoka, Fukui

- Shiitake mushroom

- Fire retardant

- Cockpit

- Penistone and Shitterton (real English places)

- Cummerbund

And then there are the ones every package blocks: "sex education", "anal cancer", "blue tit" (it's a bird), "Moby Dick", "Dick Van Dyke". A word list can't tell a medical question from an insult, because the string is the same.

If you're staying on a list, three things helped more than swapping packages:

1. Normalize before you match: Unicode NFKC (kills full-width), strip zero-width characters (U+200B to U+200D, U+2060, U+FEFF), and map look-alike letters with a confusables table. Cyrillic `а` and Latin `a` are different characters to your regex.

2. Collapse separators and repeats inside a token before the lookup, so `f.u.c.k` and `fuuuuck` become `fuck`.

3. Keep an allow list of the innocent words your list hits, and test it against real place names and surnames, not just the ones you think of.

That gets you part of the way. The rest is the reason I ended up building something.

Disclosure: I make Unprofane, a profanity API that came out of this. On the same test it caught 96.9% of the disguised swears and blocked 0 of 529 innocent texts. The test set is public, so you can run your own filter on it: github.com/unprofane/scunthorpe-test. Full results: unprofane.com/bench

Happy to share the normalization code if anyone wants it.

We just released `@acrossreport/acr-node`, a native Node.js/Electron binding (via napi-rs) that renders PDF/PNG reports in-process, backed by a Rust/Skia engine.

Most Node apps generate PDF reports either by launching headless Chromium (Puppeteer) or shelling out to a CLI tool. Both add real overhead. This links the renderer directly into the Node process instead — no Chromium, no subprocess.

- Prebuilt binaries for 6 platforms (Windows/Linux/macOS, x64/ARM64)

- Pixel-identical output across OSes

- Works in a bare Node server or an Electron main process

Write-up: https://dev.to/maskedridersystem/rendering-pdfpng-reports-in-nodejs-without-chromium-or-a-subprocess-napi-rs-b4

npm: https://www.npmjs.com/package/@acrossreport/acr-node

Repo: https://github.com/acrossreport/acr-node

Happy to answer questions about the implementation.

I ported yq to Rust so that it can be used in Node via WASM. You can install the package via npm install yq.rs or run it via npx yq.rs

We ran pboss 1.8.0 against pm2 5.4.3 on Node 24. Same server.mjs, same binary, same machine, same autocannon profile (10/100/500 connections, 60s, 5 repeats). Cold start of the whole manager stack every run, manager order alternating, CPU and RAM sampled across the entire process tree. The numbers below measure the cost of managing a server, not Node's raw HTTP performance.

Cluster mode: pboss wins almost every row

Both managers cluster Node apps natively through node:cluster, same worker count, same sharing mechanism. The only variable is the manager itself. And under that fair fight pboss pulls away at every load level.

100 connections, 2 workers:

At 10 connections pboss is still ahead: median RPS +5.6%, p99 latency 2ms vs 3ms. At 500 connections it holds: +1.7% mean RPS, better latency at p50/p90, steadier RPS. Not one row of lost throughput. Plus lower CPU across the board.

Crash recovery and restart storms, where "production ready" actually gets decided

• SIGKILL the whole fork-mode server: pboss brings /health back to 200 in 68ms median vs 128ms for pm2. Worst case across all runs: 70ms vs 194ms.
• SIGKILL one of two cluster workers: pboss respawns it in 93ms vs 151ms, worst case 103ms vs 199ms. /health never dropped on either, as it shouldn't with a survivor holding the port.
• 50-restart storm, fork: median restart 181ms vs 376ms (52% faster). Zero failures, zero orphans on both sides. But the app RSS after the storm: 58MB for pboss vs 71MB for pm2, and pboss's memory shrank 0.3MB over the storm while pm2's grew.
• 50-restart storm, cluster: 300ms vs 498ms (40% faster), workers' RSS around 20% lower, growth of -0.1MB vs +1.6MB. Again zero failures, zero orphans.

Faster recovery, tighter memory, no leaks under punishment. Fifty restarts later the tree is clean.

Startup time deserves its own section honestly

Warm cluster restarts are 43% faster. For anyone doing rolling deploys or watch-mode dev, that adds up all day.

Fork mode: mostly pboss, and here's the scoreboard

Fork mode at 100 connections, one managed process:

Clean sweep where it counts: tied throughput at the mean, +2.2% at the median, RPS stdev cut in half, 6% less memory, 24% faster cold start. The only row pm2 takes is average CPU by 0.1%, which is a tie wearing a mustache.

Across the other load levels it's the same story: pboss uses 2 to 8% less tree memory and starts 23 to 26% faster at every one.

Where pm2 actually beat us

Two-ish rows, and they're small:

• At 10 connections (a nearly idle server) pm2's median RPS was 1.5% higher and its RPS spread was tighter. On a box where the load generator shares the CPUs, that's inside the noise.
• At 500 connections, fork mode, pm2's median RPS was 1.2% higher and mean latency 1.9% better (8.58ms vs 8.74ms). Mixed row, tiny margins both ways.
• Cluster mode tree memory is 11% higher under pboss. This one is real and it's architectural: pboss runs a supervised wrapper primary above the workers, so there's one more small process in the tree. You buy it back in startup speed (30 to 35% faster) and respawn speed (38 to 48% faster). Idle daemon memory is actually 5% lower than pm2's.

That's the honest list. Everything else across the whole report goes to pboss.

Everything around it

Health checks, cron restarts, log rotation with gzip, web dashboard, Prometheus /metrics, namespaces, dependency-ordered startup, replace-first rolling reloads. Built directly on node:child_process, node:http, node:fs. Open source, GPLv3.

Don't take our word for it. Every number traces to a raw file in results/raw/, the load generator shared CPUs with the servers so compare the columns rather than quoting absolutes, and the benchmark script is three commands:

cd benchmarks/node && npm install
bash scripts/benchmark.sh

Rerun it on your own hardware and tell us what changes.

• Report: https://github.com/Procboss/benchmarks/blob/main/benchmarks/node/results/REPORT.md
• Benchmarks: https://github.com/Procboss/benchmarks
• pboss: https://github.com/Procboss/pboss

Hi everyone

I just started learning Node.js just a few hours ago, and I'm really confused (wanted to cry too). Could someone help me clarify a few things?

After I initialized a Node.js project, I see the following in package.json:

"type": "commonjs"

Then I run this code:

console.log('sync');
process.nextTick(() => console.log('nextTick'));
Promise.resolve().then(() => console.log('promise'));

The output is:

sync
nextTick
promise

Then I installed TypeScript and executed the same code again, but in a .ts file. This time, the output is:

sync
promise
nextTick

Interestingly, I get the same output when I set "type": "module" in package.json.

So I asked ChatGPT:

1. Does the TypeScript compiler change the execution order to behave like an ES module?

ChatGPT answered:

"Your tsx example produced ESM-style ordering, but you shouldn't assume every tsx file or situation will behave the same way."

Now I'm even more confused! Could someone help me clarify this?

ChatGPT's answer seems that the output when using TypeScript with CommonJS does not necessarily match the output of either CommonJS or ESM....

I also have a few related questions about the Node.js event loop:

2. As far as I know, the Node.js event loop has several phases, including:

1. Timers (setTimeout callback)

2. Poll (I/O-related callbacks, such as reading files or receiving network data)

3. Check (setImmediate callback)

Is this correct? If so, which phase runs first?

3. Are Promise callbacks handled separately from the Node.js event loop? Is the following execution sequence correct?

1. Drain the process.nextTick() queue.
2. Drain the Promise microtask queue.
3. Execute the next event loop callback (setTimeout, readFile, setImmediate, etc.)

4. Back to 1

I’m building a social media app and the server supports a WebSocket service and an HTTP service at the same port. I implemented the online status as: When the user connects using ws I update the user to be online. And when the user disconnects, I update the user to be offline, pretty simple.

My confusion comes from the lastSeen logic. Should I \ a) update lastSeen on every HTTP request and every ws event \ b) update lastSeen only when the user disconnects using the ws protocol. since I will be presenting the isOnline field only if it is true otherwise I will be presenting the lastSeen field \ c) update lastSeen on each heartbeat pong event and when the user disconnects using the ws protocol (I read that in an article linked below)

https://www.back4app.com/glossary/presence-online-status/#faq

I'm implementing a Node build tool called Nodecraft that "does more" with the most minimal configuration.

Well, I have been implementing it for about 1 week.

Shadow database

The Nodecraft build tool does not clutter any component sources --- instead, it places internal cache into hidden file system directories, which is perhaps what Golang also does.

The only thing it does place into component sources are the ".nodec" files it downloads into the ".downloads/" folder of the root component --- directly allowing portable components.

Nodecraft does not use sum or lockfiles like Golang or NPM do either. I am not very interested in that.

The graph of the N-components cache looks like what follows, and determines the UIDs for component mirrors and artifacts.

<data>/graph/ home/ PROFILE/ Documents/ katana_craft/ .tree.cfg {drive}C/ -- windows drive Users/ ... {unc}NAME/ -- windows ... {builtins}/ gnome/ 5.0.0/ .tree.cfg ... {registry}/ ko.da.ka/ 1.0.0/ .tree.cfg {git}https{}gitlab.com/ group/ repo/ {rev-REV}/ ... .tree.cfg

The .tree.cfg file is a JSON file w. the following properties.

configuration = lastModified = lastOpen = # RFC 9557 date-time main = id = testSuites = id = buildPreprocessing = id = directs = { [URL(1), SemVer Range], ... }

These graph folders can also contain .build.cache files, JSON forms w. the following properties, used for PAYG-style builds.

main = unitGraph = Map "path/to/unit" -> (last modified, List of "path/to/unit") testSuites = unitGraph = buildPreprocessing = unitGraph =

The following folders are where .nodec mirrors + build artifacts go in.

``` <data>/mirror/ <UID>/ Mirror sources extracted from files of the ".nodec" component extension.

<data>/gen/ <UID>/ Executable JavaScript units, plus any embeddable files.

<data>/headers/ <UID>/ Header JavaScript units (type hints only)

<data>/pre/ <UID>/ Build preprocessing artifacts. ```

File system

Nodecraft uses URLs in the following forms to identify components and subtree entries.

The /+/ path component is required for distinguishing the Nodecraft component path and a subtree entry.

file:///path/to/component file:///path/to/component/+/path/inside git+https://gitlab.com/<group>/<component>/{rev-<FRAG1-FRAG2>} git+https://gitlab.com/<group>/<component>/{tag-<TAG>} git+https://gitlab.com/<group>/<component>/{br-<BR>} git+https://gitlab.com/<group>/<component>/{br-<BR>}/+/path/inside registry:ko.da.ka:1.0.0/+/path/inside builtins:tg1-commons:1.0.0/+/path/inside

digging inside the build artifacts

• prefix the scheme w. "h+" for .es|js -> .es|js header units
• prefix the scheme w. "gen+" for .es|js -> .es|js final codegen units
• prefix the scheme w. "pre+" for artifacts resulting from build preprocessing (no source files included)

Tutorial

A Nodecraft component could look like the following source tree.

[begin:folder] load.es node.cfg [end:folder]

The file called "node.cfg" could be as follows.

```yml

$schema=http://www.ryujinx.com/nodecraft/1.0

ID: ko.da.ka:1.0.0

direct: - builtins: node:1.x ```

The file called "load.es" could be as follows.

print("skript")

That can be generated by running the command that follows, along with a file called "code.cfg" that contains code style configuration (the indent sequence, for example).

sh node new ko.da.ka

[begin:commentary] For what it is worthy, the above is a tighly-configured JavaScript 1.x unit ("TypeScript"). [end:commentary]

Evaluate that component by running the command that follows.

sh cd ko.da.ka node eval

The GitLab project

There is quite a bit to it yet. I need to finish loading directs ("dependencies") and unloading components and any directs in memory, and implement the build.

https://gitlab.com/ryucorp/nodecraft/nodecraft/-/blob/master/doc/tutorial.md?ref_type=heads&plain=1

https://gitlab.com/ryucorp/nodecraft/nodecraft/-/tree/master/doc?ref_type=heads

a thread here last week asked what happens to inbound webhooks when your endpoint is down. most answers were "the sender retries", which is true for some providers and not for others, so here is the setup I'd use so it stops mattering.

The handler does four things and nothing else: verify the signature against the raw body, insert the raw payload into a table with the provider's event id as a unique key, return 200, done. No parsing, no business logic, no calls to other services. A bug in your parsing code then can't lose a message, because the message is already stored.

A worker picks up rows with status pending using SELECT ... FOR UPDATE SKIP LOCKED, processes them, and marks them done or failed with an attempt counter. Replaying a message is just setting its status back to pending. The unique key makes duplicates harmless, and providers do deliver the same event twice.

Keep the receiver deployable on its own. Most gaps I've seen came from restarts and deploys of the main app, not from real outages, so a tiny separate service (or a queue in front) removes most of the risk. Then once a day compare the provider's delivery log against your table, which catches the cases where the sender gave up after its retry window.

In Node this is a small amount of code: express.raw() for the body, crypto.timingSafeEqual for the signature compare, and pg for the table. The classic trap is express.json() running before the signature check. It changes the bytes, and valid signatures start failing.

What does your setup look like, and which providers have burned you with short retry windows?

I built a craigslist scraper using selenium. For selenium I am using chrome which requires a chromedriver executable. This all works fine.

Every 3-4 weeks chrome updates to a newer version and I get an error that chrome and the chromedriver executable have mismatched versions. So I then manually find the new version of the chromedriver executable, download it, unzip it and drop it in the directory alongside my index.js - and everything is fixed.

How can I automate getting the newer version of the chromedriver executable? I could just write code to do all that. But I've also been looking at the npm chromedriver module. I can't tell if the chromedriver module is what I need.

inbound mail on hooks@ gets posted to my api as json, signed so I can check it actually came from the mail side. no imap polling, which was the whole point, imap is a pain.

question for people doing this in prod, what happens when your endpoint is down for a few minutes? do you rely on the sender side retrying, or do you keep a copy and replay? I’ve read stories where the mail is just gone forever and that scares me a bit.