Are your test suites large, slow, vacuous, or incapable of achieving full coverage?

Have you spent moonlit nights debugging something that should never have reached production?

Worry no more, friends. With test-nirvana, all of this is resolved through a single command: npx test-nirvana

Unlike conventional testing tools, test-nirvana validates what actually matters:

• The code is the right shape.
• It is the right time for the feature.
• The stars are correctly aligned.
• The commit hash possesses an acceptable aura.

Each commit is reduced to its numerological destiny number and classified. CI-friendly exit codes ensure that compromised commits cannot reach production.

Github repo

npm

Note: All MIT License guarantees are void while Mercury is in retrograde. See LICENSE for the complete celestial warranty condition.

Stateledger is a database-backed state machine for Node.js. Every transition is persisted as a row with the actor, timestamp, and metadata. Transitions use Postgres advisory locks so concurrent requests can't both apply the same transition.

v1.0 also includes @stateledger/outbox, which implements the transactional outbox pattern for external side effects that need to commit atomically with a state change.

The API looks roughly like:

    import { defineMachine } from "@stateledger/core";
    import { enqueue } from "@stateledger/outbox";

    const paymentMachine = defineMachine({
      name: "payment",
      states: ["pending", "processing", "captured"] as const,
      initialState: "pending",
      transitions: [
        { from: "pending",    to: "processing" },
        { from: "processing", to: "captured" },
      ] as const,
      callbacks: {
        "after:pending->processing": async ({ tx, subject }) => {
          await enqueue(tx, {
            kind: "payment.processing",
            payload: { paymentId: subject.id },
          });
        },
      },
    });

    await machine.transitionTo("processing");

There are currently Prisma and Drizzle adapters, 26 integration tests against real Postgres using Testcontainers, and the project is MIT licensed.

This is not intended to replace XState. XState is primarily useful for modeling application/UI state in memory. Stateledger is focused on persistent server-side state transitions where concurrency, audit history, and transactional side effects matter.

I'd particularly like feedback on the outbox API. I'm interested in how people currently handle state transitions + external side effects in Node/Postgres systems and what's missing here.

GitHub: https://github.com/enowdivine/stateledger

I've found that as projects grow, it gets harder to keep architectural boundaries consistent. Some rules live in docs, some live in code review, and some just live in people's heads. I've run into the same problem with coding agents too. Even when you tell them how the project should be structured, there's nothing actually enforcing that they follow it. Over time, that kind of architectural drift can become pretty painful to unwind.

I've been working on an open source TypeScript tool called Semarch, to experiment with making those conventions enforceable.

For example, say a project has users and billing domains with services and repositories:

users.service -> users.repository     allowed
users.service -> billing.service      allowed
users.service -> billing.repository   denied

In Semarch, you classify your files:

domains:
  users:
    root: src/users
  billing:
    root: src/billing

components:
  service:
    match:
      - "**/services/**/*.ts"
  repository:
    match:
      - "**/repositories/**/*.ts"

Then define the boundaries:

rules:
  - deny: service -> foreign.repository
  - deny: service -> transport

Semarch analyzes the TypeScript dependency graph and fails the check when one of those boundaries is violated.

You can try it with:

npm install --save-dev semarch
npx semarch check

It uses the project's tsconfig.json for module resolution, handles path aliases and type only imports, and follows static re-exports/barrel files so they can't trivially bypass a rule.

I know there are already tools in this space, so I'm particularly interested in whether this model with domains, component roles, and local/foreign relationships is actually useful for real projects.

This is still experimental but if you maintain a TypeScript project with architecture conventions like these, I'd really appreciate hearing your thoughts on this approach.

It's MIT licensed and open source.

GitHub: https://github.com/ConnorNail/semarch

I wrote this and I maintain the tool, its Apache-2.0, no hosted service, no telemetry, bring your own key. The corpus and eval harness are in the repo under evals/semantic/ if you want to run it against your own language pair or a different judge model.

i need some reliable material for using Express.js with Typescript since the resources not that common compared with using Javascript

I am using asymmetric encryption in my mobile app, in the backend i am using nodejs and supabase. I wish to know if there is any newwer and advanced version of the jose library to achieve this in nodejs?

I recently published a new django like admin npm package for managing your database.

its called paneljs. it currently has support for prisma and typeorm more support for other orms coming soon

A practical look at cloning and transferring data in Node.js, including workers, class instances, Buffer becoming Uint8Array, detached ArrayBuffers, and unsupported values.

I search a django equivalent framework app based approach does this exist in node or maybe other runtime ?

been building an api key system this week (well was a week task i stretched a bit). auth, refresh tokens, rate limiting, all that boring stuff.

thought the hard part would be the actual auth logic.

it wasn't.

first postgres decided to stop booting after i bumped the image version. just kept dying with an error about the data directory. spent probably an hour looking at the same error and assuming something else was wrong.

turns out postgres 18 changed how the data directory is supposed to be mounted.

so yeah, the error was basically telling me exactly what was wrong and i just didn't believe it.

then had another stupid one with refresh tokens.

tokens were expiring after like 10 minutes instead of 7 days. no errors, nothing crashing. everything looked fine until I actually tested it.

eventually figured out i was storing the expiry in seconds, while the cookie maxAgeexpects milliseconds.

so i was basically off by 1000x.

the part i actually liked was the api key hashing problem though.

initially i was thinking, just bcrypt the api key and query the db with the hash. then realized that doesn't work because bcrypt salts the hash, so the same key gives you a different hash every time.

my next thought was "fine, just loop through all the keys and compare them."

which obviously becomes a terrible idea once you have more than a few users.

ended up doing what is apparently the standard approach separate public lookup id + hashed secret.

later found out that's basically how Stripe and GitHub handle it too, which was a nice little confirmation.

nothing here was particularly difficult. most of the time was just me making assumptions, staring at the wrong thing, and eventually reading the error properly.

Not gonna tell that the repo is public if anyone wants to have a look (don't do it).

curious how other people handle the key lookup/hash part though if you actually built one.

I’m experimenting with a small in-process error alerting layer for Node services. The hard part isn’t sending a webhook—it’s keeping repeated errors from becoming noise.

Right now I’m thinking about grouping by normalized error type, counting occurrences, adding first/last-seen times, and redacting before anything leaves the process.

For a small service, what information do you actually want in the first alert? What becomes noise quickly?

​

I built NodeForge, a small CLI tool that automates the initial setup of a Node.js backend project.

Instead of manually creating the same folders and boilerplate every time, you can start with a single command and get a structured project with:

- Node.js + Express setup

- JavaScript or TypeScript support

- Controllers

- Services

- Routes

- Models

- Validations

- Serializers

- Utils

- Seed structure

- Basic project configuration

You can try it with:

npx @jain_daksh/nodecli

I built this mainly because I was tired of repeating the same Node.js setup whenever starting a new project.

This is my first published NPM package, so I'm also looking for feedback from other developers.

If you have a minute, check it out and let me know what you would improve or add.

NPM: https://www.npmjs.com/package/@jain_daksh/nodecli

This is just phase 1 in phase 2 more things coming

You can read the medium article here https://medium.com/@jaindaksh/i-got-tired-of-setting-up-node-js-projects-manually-so-i-built-my-first-npm-package-6dcd9db042e8?source=rss-a43d55f9817e------2

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

I just published solid-objects. It's an early release (MIT licensed) of an open source Durable Objects library. I know celld just came out a few days ago, but I don't want to run yet another daemon on my infrastructure. I am looking for feedback more than stars.

Code: https://github.com/cardmagic/solid-objects-js

The problem: Game tables, chat rooms, AI chatbots, live collaborative documents... managing state and real time views of these kinds of things has traditionally been pretty hard. This solid-objects library makes it a breeze.

What it does: each {class, id} gets a durable, ordered mailbox. Calls to one ID run in order. Calls to different IDs run at the same time. State, retries, reminders, effects, and realtime invalidations live in the SQL database you already run. No Redis.

An example model:

class Cart extends Actor {
  static override readonly actorType = "Cart"
  items: string[] = []
  add({ sku }: { sku: string }) {
    this.items.push(sku)
    return this.items.length
  }
}

const cart = runtime.ref(Cart, "cart-123")
await Promise.all([cart.add({ sku: "shirt" }), cart.add({ sku: "hat" })])

Both calls enter the mailbox for cart-123 and commit one state transition at a time, even from different Node processes.

A deployed app that uses it: https://shuffleupandplay.com/ (source https://github.com/cardmagic/shuffleupandplay )

If you're already on Postgres or MySQL: is per-ID ordering a real gap, or do you just compose row locks and queues yourself? What would stop you from using something like this?

Thanks for the feedback!

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?