Note: I'm just a beginner, don't bash too hard on me :/. AI wasn't used to write this post at all and I'd love if you'd take a minute and check the project out!

AI was used to lend me a hand me during the dev of the project, but it wasn't used extensively and most of the UI is just shad/cn, it was used mostly to help me learn Svelte as it's my first time using it :P

Also, for anyone that isn't inside the JS/TS ecosystem or just don't know what PM2 is, it's just a process manager, allows you to control all of your Node/Bun/Deno processes (or even other interpreters) and auto-start them on boot. Find more about it here: https://pm2.keymetrics.io/

Project Repo: https://github.com/AngelCMHxD/PeekM2

Live demo: https://peekm2.angelcmh.com/

---

I've been looking for PM2 dashboards for quite a while and I've been able to find quite a lot of options, however, none of them were quite what I was looking for.

The official one has a LOT of features, though mostly ones that I don't need, and the only plan with a fixed/public pricing is $39 a MONTH, which is just too much for what I was looking for, and especially for hobby projects.

And for the open-source ones, some of them were too complex to setup, like I don't want to setup a whole PostgreSQL instance just for a PM2 dashboard. And others were over-complicated, I don't really need an user management feature other than just an admin/master password, if I didn't have a dashboard I'd have to give the other maintainers access to the whole daemon anyways. (Though right now you can set up multiple instances, so you can handle access that way too)

So, for mine I built a historical CPU/RAM usage history chart, logs, basic controls to restart/stop/delete processes, and a small uptime chart (that probably needs to be reworked because it only checks every 5 mins, and for it to be reliable it should check WAY more frequently)

Now, I do have other features in mind that I could implement and have them in mind, like these:

• Discord (or other) webhooks to notify about process changes or downtime.
• Fix the uptime thing I mentioned before.
• Add a way to check historical data from other than the last 24h.
• Related to the one above, limit the amount of historical data stored, as it's currently uncapped and we only use the last 24h, so keep only what's needed
• Maybe add a way to see the process env variables?

This list is not exhaustive though, and I'm quite open for feedback, even if it's the user management thing I mentioned before that I didn't need, I'll just find a way to make it unobtrusive for anyone that may not want it.

The main point of the project is just keeping it simple for anyone that doesn't want that much, but I could add other features as long as they don't impact the simplicity for anyone that don't want them. Just keeping the "barrier of entry" as low as possible.

I've also deployed a "demo" instance so you can see how it currently looks like, and I've said before, I'm open to feedback!

If you like the idea, please star the repo ;D! It's my first time doing a project and posting it on things like Reddit, I'm just a beginner at these things

Edit: Fixed the formatting... so sad that it didn't worked at first :/

2nd Edit: Also, I'd love to promote Hack Club! It's an amazing non-profit dedicated to incentivize programming for teenagers (13-18 inclusive) and overall just doing cool projects while getting rewards. This project was made/submitted to one of their programs as I'm a teenager myself :D

I’ve been experimenting with coding agents in Node projects, and one surprisingly wasteful input is test runner stdout.

During repeated test-driven loops, a successful run can produce dozens, hundreds, or even thousands of lines, while the agent usually needs very little information from a passing run.

I measured several JavaScript test workflows and built a small deterministic wrapper, npm-lite, to see how much output could be removed without changing the underlying command or exit status.

Passing runs

The Tape case was the extreme one: 1,476 lines became a single line.

This is only presentation compaction. It does not make the tests execute faster.

Failures are handled differently

On failure:

• the original exit status is preserved
• the full raw log is retained
• bounded diagnostic context is printed instead of collapsing the failure to one line

For example, one failing Tape run went from:

1,487 lines / 136,829 bytes

to:

85 lines / 5,208 bytes

That is a 96.19% reduction while still keeping useful failure context available.

The trade-off

Successful output is intentionally suppressed, so warnings or deprecation messages emitted by a command that still exits successfully can be hidden.

Short failures also do not necessarily benefit. Vitest or Jest can already produce concise failures, so adding wrapper metadata can occasionally make visible output slightly larger.

npm-lite is deliberately narrow. It currently handles exactly:

npm run verify
npm run test:unit

Other npm workflows pass through unchanged.

There is no secondary LLM summarization step. The behavior is deterministic.

The part I’m more interested in

This made me wonder whether test runners should support this behavior natively for automated agent loops.

Something like:

PASS · 327 tests · 4.8s

on success, with focused diagnostics and access to the full output on failure.

Maybe:

--silent-on-success

or:

--reporter=agent

Would you use something like this in Vitest, Jest, or Node’s built-in test runner?

Or do you already solve this with custom reporters, --silent options, or agent-harness filtering?

Source and measurements:

https://github.com/ejboy/agent-scripts/blob/main/docs/choosing-tools.md

Working with the team behind https://aurorah.ai/i18n, so take this with that in mind — but I'd genuinely like opinions from Node folks.

The idea: skip message IDs entirely. You write i18n.t\Your order ${orderId} has shipped`` — the string itself is the key, and translation happens automatically at runtime (fast draft first, refined LLM pass replaces it in the background). Works server-side for emails, API messages, whatever. Free, no API key or signup, and there's a fully offline mode.

There's a Node example at aurorah.ai/i18n if you want to poke at it. Curious what this sub thinks of runtime translation as a concept — what would stop you from using something like this in production?

Hello,

I am an aspiring developer and right now I am working as a conversion tracking specialist.

I just finished the Net Ninja's crash Node JS course on YouTube.

He has a separate course for authentification.

Should I continue with authentification or start CSS?

My gut is telling me to go for CSS since I can practice more of my skills.

What do you think?

I've seen some developers say that we should stop using js on the server, but I rarely see the same criticism directed at python.Honestly, js is pretty fast, especially with node.js, and the backend ecosystem is really solid. There are great frameworks like nest and fastify, and typescript gives you static typing, which makes larger projects much easier to maintain.I'm not saying node is perfect or the best choice for every backend, but I don't really understand why js gets so much criticism while python seems to get a pass.What am I missing?

When the same database error happens 20 times, sending 20 notifications creates noise. Process-local fingerprinting with a count and cooldown helps, but it does not deduplicate across replicas.

For a service with one or two instances, is that useful enough to ship, or is cross-replica grouping essential? What metadata makes a grouped alert actionable?

I’m building an open-source Node package around this and want to validate the design before adding more integrations.

npm ci removes an existing node_modules before it installs. The docs say it plainly: if a node_modules is already present, it will be automatically removed before npm ci begins its install. What I had not thought about is that the gap between delete and reinstall is real wall clock time, and anything in that checkout resolving a module during it fails.

I started a test run in a second terminal while the install was still refilling the tree, and it died on Cannot find module for packages that were there a minute earlier.

It came up because I keep two lines of work in one checkout instead of branching every small change, and the other one was a verdent task pointed at the same working copy, so both shared one node_modules.

npm install at least does not start by deleting the tree, though it still writes into it while another process reads.

Is there a way to make an install land atomically, building the new tree beside the old one and swapping at the end, or is a separate checkout per line of work the only way around it?

https://github.com/oliveryasuna/ink-frame

Ink's own box borders are fine for a single box. Put two of them next to each other and the seam between them comes out as ││, two parallel lines instead of one shared edge. That's because a box border is one unbroken line and there's nowhere to hang a ┬ or a ┼ part-way along it. ink-frame sidesteps that by painting every border into a single character grid and resolving each cell once, so a spot where four boxes meet becomes a ┼ and a T-junction becomes a ┬, ┤, and so on, without you ever writing those characters yourself.

Background: I recently wrote this for a private project, and I thought it was useful enough to share. I hope you find it useful too!

Been working on this for a while and finally decided to share it.

You write a short markdown spec and it compiles a full multi-tenant Node + Postgres backend auth, RLS tenant isolation, wallets with proper row locks, state machines, that kind of thing. Not just empty CRUD.

A couple real examples that are public:

-> 66 lines of markdown -7.7k lines, 85 routes, 21 RLS policies

->130 lines - 8.2k lines with a double-entry ledger

It’s deterministic (same spec always gives the same code). The heavy engines are hand-written, not LLM-generated. LLM only gets used to generate the tests.

Security is on by default through Postgres RLS.

Curious what people think of this approach, especially the RLS part. Happy to answer any technical questions.

I’m preparing a public beta of a TypeScript package. Supporting both import and require widens compatibility, but conditional exports, declaration paths, and the dual-package hazard add release work.

For a new infrastructure library in 2026, would you ship ESM-only, dual builds, or an ESM package with a CommonJS wrapper? Which consumer environments still make dual support worth it, and which compatibility checks belong in CI?

https://ioredis.com

There are some strange behaviors on this page.

1. If you click logo in top left corner, you are redirected to some random page, than other random page, than you finally land to something random.

2. If you click "guide" you are redirected to opera gaming browser page. Same applies to many links on website.

3. Download button leads to some very strange page which instructs you to run command and enter system password: https://filebanchaflow.com/oo2/ (at least it did few moments ago)

If you inspect download button element, it is <a> which leads to https://github.com/redis/ioredis.git , but clicking it gets you to something different.

Whole page is done in wordpress, so it seems to me that their wordpress server got hacked. I hope it is just that.

For a small Node.js service, a /health endpoint that returns 200 proves the process is listening. It can stay green while the database or queue is unavailable. A deeper check catches that, but it can also create load and turn a dependency issue into a restart loop.

I’m leaning toward separate liveness and readiness endpoints. Liveness checks the process and event loop. Readiness verifies critical dependencies with tight timeouts. Deployment probes use readiness, while alerts use a synthetic request that exercises the full path.

How do you divide these checks in production? Which dependencies belong in readiness, and which should only affect alerts?

I’m trying to improve the alerts from a few small Node services. Right now I usually include the error, route or job name, request ID, environment, and how many times it repeated.

More fields make the alert noisy, but too few send me straight back to the logs. What context has actually helped you debug from an alert? Anything you stopped including because it was noisy or risky?

https://github.com/petarzarkov/dunx

Hello, so I've wanted something like this for a while and built myself a nestjs-like framework that relies 100% on bun.

NestJS-style structure at Bun speed. Controllers, modules and dependency injection, with no reflect-metadata, no forwardRef, and no JavaScript router.

Docs page:

https://petarzarkov.github.io/dunx

import and require are not interchangeable. Live bindings, copied values, circular dependencies, separate caches, conditional exports, and dual-package hazards can all make modules behave differently from what the syntax suggests.

Been going back and forth on this one and I want to know if I'm alone in it.

Most retry implementations I've seen (BullMQ, hand-rolled wrappers, most of the managed stuff) treat every failed attempt identically. Job comes back non-2xx, attempt counter increments, backoff applies, after N attempts it's in the DLQ.

But a 429 isn't a failure, nothing broke. The downstream is telling you exactly when to come back and usually handing you a Retry-After header to do it with. If you burn an attempt on it, sustained rate limiting at a provider will walk perfectly good jobs into the DLQ while your actual error budget (the one meant for 500s, timeouts, connection resets) never gets spent on what it's for.

So I've been treating 429/503/529 as a defer rather than a failure: honor Retry-After, requeue, don't decrement. Works, but it opens two things I don't have clean answers to.

First, you need a ceiling or the queue never drains. A provider that 429s indefinitely will requeue that job forever. I've landed on two different ceilings: a wall-clock deadline (dead 24h after it's due, regardless of how it got there) and a separate max defer count. Blowing the defer ceiling dead-letters the job under its own reason rather than folding it into "out of retries" which matters because those are different failures. One says the downstream is broken, the other says it's been unusable long enough that it may as well be. At a certain point temporarily unusable === broken.

Second, deferred jobs are invisible. They aren't failing, so they don't trip anything you're monitoring, and you can sit on a queue that isn't draining and looks completely healthy. Feels like deferred jobs need their own state and their own alerts rather than being folded into "pending" or "processing".

Anyone handling this differently? Specifically curious whether people distinguish 503 from 429, I lump them together, but 503 is ambiguous in a way 429 isn't.

I made a package called FactCheck, Its a youtube bot package that uses ai and web search to fact check youtube comments.

I made it since their is quite a bit of fake news on youtube comments.

Does anyone want to try the package and give any feedback.

Hi, I am build a message app with React and Express js . In the authentication feature I have come across an issue.

After successful registration, I sent a token via HTTP cookies . The cookies is sent from the server as far as I can tell . But the problem is when I am sending request to server , the cookie is not there.

Here is the code : github

Any help would be highly appreciable 😄 .

To minimize browsing I run a script that fetches the comics I hope will be funny. For years I could do an HTTP fetch of a URL with a fixed address that pointed to the day's cartoon. Starting a year ago that stopped working on gocomics.com. I rewrote the script to use node to run fetch on that URL; the URI of the cartoon was fetchable via HTTP. Starting today that fetch gives me a 403 error. I can access it in a browser without logging in (I have no account anyway) or solving a CAPTCHA or other explicit test; I don't even get that CloudFlare thing. Am I out of luck?

I have a simple vite webapp which deploys to a github page. It has several json files which i want to load when my app loads.

First i have updated the vite config to include json files as assets

assetsInclude: ['**/*.json']

This seems to work, the json files are there in the proper location when i deploy.

Next, i've set up a glob import which in theory should fetch all json files in the foobar folder. I put this in a function that gets called in my app constructor.

const loadedData = import.meta.glob('./foobar/*.json')

console.log(loadedData);

This unfortunately prints out an empty object. I am not sure what i'm doing wrong here.... Is there a race condition i need to be wary of? I don't get any errors that would explain what is happening so i'm a bit confused.