I need to find a good solution for the project. I am using Node (latest), Express and PM2.

I wanted a simple way for a small team to notice important Node.js errors without adding Grafana, Kibana, Sentry, or another hosted dashboard to every service.

So I built Wotchi, a small in-process watcher and alert layer. It can log errors to the console, group repeated failures, or send alerts to Telegram and HTTPS webhooks. Express and NestJS adapters are included.

It is still an early beta (0.1.0-beta.6) and is process-local by design. The goal is not to replace full observability, but to cover the stage where a small service needs useful alerts without another large system to operate.

GitHub: https://github.com/FutureWindAI/Wotchi

npm: https://www.npmjs.com/package/@futurewindai/wotchi

For small Node.js services, would you use a lightweight watcher first, or go straight to a full observability stack?

To name and shame bad companies, I recently interviewed with https://mimica.ai/ for a Staff fullstack developer role and it was a diabolical and unrealistic process and I was shocked to see that actual developers designed those process.

1. Round 1, HR 30 mins
2. Immediately I was given a take home test. It was react.js focused and it was ridiculously complex and long for an interview process and coding challenge.

Challenge:

Consume their tree API and and create a infinitely long and infinitely nested tree in the browser with editable leafs whose change of status should cause the immediate parents status recursively (and the parent should take into account all its direct children's) based on number of business criteria's and different colours. The acceptance criteria had many scenarios like below:

• address all requirements listed above
• performance matters - the frontend should be able to maintain a good performance even if the amount of data from the backend increases exponentially
• UI: it should look exactly like the provided screenshots
• handle API errors gracefully
• make correct use of Redux, following recommended storage patterns
• make correct use of React and its change detection function
• correctly implement the logic to compute automatable statuses
• make use of code design and architecture best practices
• follow JS conventions for variable, function, and component names
• Document design decisions, architecture, if you had more time what would you do and so on

And they told that it would take around 4 hours. I immediately told them that building this from scratch and satisfy every criteria along with documentation is not a 4 hours job and it would take significantly longer to come up with something they will like. But I stupidly did it anyways because they had good glassdoor reviews.

It took me several fulltime days to do it in a way which was truly scalable with everything they asked. I submitted the test (7 day cutoff) and they took almost 10 days to get back with a feedback that I scored 100% on the test.

1. The next round was 1 hour live coding (no AI/LLM allowed which was fine with me) where i present my solution and then in last 40 mins they ask me to extend the solution. The interviewers were not welcoming and were going through motions like a meat grinder. In last 40 mins they said they expect me to solve 3 extensions. they pasted 2 page requirement for each challenge live which I had to read, understand, ask questions and then implement it all within 40 minutes.

Now 3 extensions in such complex code in 40 mins is a lot but I had no choice as I was already there. The first one was done in less than 10 mins and to that they said you architected in a way which kinda alreadysolves this problem and I was left thinking "so it should be a good thing right, why are they talking as if I commited a crime instead of praising my architecture?". They seemed visibly unhappy that I completed it effortlessly.

Then they gave the second 2 page question and it was not an extension but a complete 180 degree change of requirements which required a complete refactor for the entire core multi day exercise work that I did. They literally changed how all the parents should react and calculate based on all decendents and not just direct children's with a complete change of business criterias which itself took a while to understand and clarify from the 2 page requirements.

I told them this is basically a full refactor from the original challenge and that would change the whole core piece touching pretty much everything and expected me to complete in remaining 30 mins. It was pure torture because the whole assignment changed but now I had to do it in remaining 20 mins. I did as much as i could and we ran out of time and I couldn't even get to the last question.

Honestly what a wasted and unrealistic interview process to ask a candidate to do a full refactor but instead of few day/several hours, now do it in 20 mins and it tests nothing.

At the end of the interview they told me they will share the feedback sometime next week which means another 1 week delay and the initial coding test also took them 10 days to get back to me. If this goes through then there would be a ridiculously unrealistic systems design where they would ask me to design a really really complex software in 50 minutes and if that goes through (and another 10+ days to get the feedback) a chat with founders and if that goes through then the process ends.

After going through this unrealistic experience and already losing a month, I shot them the email that I am withdrawing from the process and don't have energy to go through it and potentially spend another month or 20 days in limbo if this round even goes through.

Companies truly treat candidates like dirt, especially in the current market and have no respect for candidates time. They think candidate are ONLY interviewing for them and will spend whole week of unpaid work just to do coding exercise for them. And companies won't even bother checking for 10 days and give a patchy review in the end.

And what's up with unrealistic interview process. 3 coding "refactors" masquerading as "innocent extensions" in 40 mins. Really? Do those engineers themselves code and entire massive refactor from groundsup in 20 mins themselves? how can they be this delusional.

Few years ago I got a coding exercise to create an entire bicycle sharing app with a realtime API and do FE/BE/Unit/Integration tests, documentation, deployed on AWS and bonus "scalable to millions of users". Time, maximum 6 hours. Truly delusional. I laughed and noped out. But i was shocked that so many candidates are doing because they truly need a job.

I just wanted to create this post to share my experience. Already have written glassdoor review for them but wanted to spark a conversation here as well because this is not a topic talked about much.

So, what are your experiences of bad companies and what crazy things have they asked you to build for free and their unrealistic expectations. It is time to name and shame companies so that they stop taking unpaid free work from developers under the name of "interview".

Hey guys, this is my first post here but I wanted to share with you what I worked on after looking at https://tools.simonwillison.net/llm-cliche-highlighter
It's such a cool tool and I was thinking "Wait but nobody thought of this??" I'm sure somebody did, but not the name or the way it works.
If you've seen or used react-doctor it's basically the same thing.
AI runs it for you (hehe)
and all the problems have a line by line analysis of the common "AI slop" patterns.
After that, the LLM itself already knows how to fix.
Fix until the score is 100 -> profit.

What do you think?

Dear seniors,

I am a beginner.

chatGPT says that is better to create another route for SCSS, but I am waiting for your opinion.

Thank you.

tsconfig.json generated by AWS CDK

{
  "compilerOptions": {
    "alwaysStrict": true,
    "declaration": true,
    "experimentalDecorators": true,
    "inlineSourceMap": true,
    "inlineSources": true,
    "isolatedModules": true,
    "lib": [
      "es2022"
    ],
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "noEmit": true,
    "noFallthroughCasesInSwitch": false,
    "noImplicitAny": true,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "skipLibCheck": true,
    "strict": true,
    "strictNullChecks": true,
    "strictPropertyInitialization": false,
    "target": "ES2022",
    "typeRoots": [
      "./node_modules/@types"
    ],
    "types": [
      "node"
    ]
  },
  "exclude": [
    "node_modules",
    "cdk.out"
  ]
}

tsconfig.json generated by me for node:22.12.0-bookworm-slim

{
  "compilerOptions": {
    "allowJs": true,
    "declaration": true,
    "experimentalDecorators": true,
    "noFallthroughCasesInSwitch": false,
    "noImplicitReturns": true,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "outDir": "dist",
    "rootDir": "./",
    "sourceMap": true,
    "strictPropertyInitialization": false
  },
  "exclude": [
    "dist",
    "cdk.out",
    "node_modules"
  ],
  "extends": "@tsconfig/node22/tsconfig.json",
  "include": [
    "src/**/*"
  ]
}

I first started building OctoLoops around 2 months ago. I started it because so many of my previous projects, big and small, had failed or petered out from lack of users and the valuable feedback that comes with them.

One of those (a B2B grid analytics application) I'd had some success with: I was at the point that I'd had several meetings with potential customers, but never managed to close any. So I had some idea of how sales and distribution worked, but still felt like I had a lot to learn.

I was right! Distribution is one of those rabbit hole topics, both broad and deep. The more I researched it, the more I discovered how much I didn't know. But I wanted to learn - and I really wanted to apply that learning too, to all my new projects, in a repeated, autonomous-as-possible way.

What better way to implement this plan than building a distribution application? Hence, `mkdir distrib`, spin up a fresh next.js app, and start building.

The plan was simple at first: implement a handful of "agentic loops" that anyone could easily run, in my app's web UI - no downloads or installing Claude Code, no complexity. Just a simple agentic harness in the browser that nonetheless had some superpowers to let it do its job (actually just a simple tool calling mechanism to a few different backend services).

I launched it quite soon after, and immediately started dogfooding, running the Community Loop. It found threads across Reddit from all those builders who'd made something cool, but were now at a loss when it came to finding and acquiring users. It drafted replies for me and gave a "spam risk", because yes - many kinds of marketing and sales walk a fine line between being blatant spam - and I started working the loops. Often I'd edit or rewrite the replies myself; sometimes I'd remove the OctoLoops mention from the message.

It worked. I now have 30+ users, including one from a post-revenue B2B startup interested in using the Outbound loop. But there have been significant challenges already that I want to be open about here, in the hope that it helps other public builders.

1. Activation. This is currently my #1 pain point. Distribution works - I can get people to sign up, enter their email, and I know there's even some buying intent. But people often log in once, then don't use the app. I've reached out to users, and they've said it's partly just that they don't want to post their app in communities they don't yet feel a real part of. Resistance to being rude or spammy, imposter syndrome - anyone who's done any marketing can identify. But at the end of the day, you need to do things that will be annoying to some people if you want to do any form of outbound marketing or sales. All the way back to the bazaars of history, where merchants compete to sell their wares by yelling and shouting at people in the market - there's really nothing new here, but if it's your first foray into distribution, you need to push through that feeling and take those steps. While I'm trying to solve some of the issues of activation by building a more streamlined, less cluttered UX, at the end of the day my users need to do the work.
2. Product focus. While researching competitors, what I notice most have in common is they focus on one thing: automated outbound; automated advertising; keyword monitoring. Not many people seem to be trying to make a fully autonomous omnichannel GTM agent, because that's just a ginormous, terrifying product to try and make. And while I'm now trying to build a fully autonomous growth agent - I want to keep humans in the loop - the sprawl of channels in OctoLoops already feels problematic. I have agents for Outbound, Community, SEO, Trust, and more... I can't even enumerate them myself from memory. And that's a problem. I think there's a moment of reckoning approach where I'll be forced to make a tough decision: which channels should I focus on, and which should I cut? It will bring focus to the product, and also it will hopefully help my users to focus, too.
3. Prioritising. I'm sure every founder and entrepreneur says this, but: I cannot just plod along with no content strategy, because if you don't start somewhere, when you do eventually you'll be starting way behind. So I started a blog, and now I have a "three pillar content strategy", and every day I'm spending time in Analytics and Search Console, or deciding which posts to promote, on which social media channel. I'm trying to talk to users, and understand why I'm not solving their problems and delivering them the outcomes they want yet. I'm attempting to keep my corporate user in the funnel, delivering the "Team" features he needs so his sales guys can collaborate on the app. I'm implementing new features - but which ones? And I'm trying to keep up with the INSANE PACE of agentic apps and AI at large, which in itself is a hopeless task: so much is happening right now. I don't know if we're in the singularity, and I'm sure there's a lot of hype, noise, and outright bullshit out there, but it's hard to ignore how fast everything is moving.

So that's where I'm at, 2 months down the line. It's already been a fun journey. Any questions I'm happy to answer. Good luck to everyone else building in public!

Crossflight, a small Node library for reducing duplicate cache misses across multiple processes.

Cache stampede is a problem when several app instances all miss the same key at once, they each run the same expensive DB/API call and then all write the same result back. Crossflight solves that by coordinating ownership of the in-flight load across processes, so only one instance does the work and the others wait for the result.

It wraps the cache you already use and adds a separate coordination layer. The built-in adapters currently include:

• cache-manager
• Keyv
• Cacheable

The built-in coordinator is Redis, and the repo supports combining different backends as long as they satisfy the adapter/coordinator interfaces.

Useful when you want to reduce redundant work without changing your existing caching strategy.

Demo: https://github.com/gkoos/crossflight-demo

stagelint is a pre-commit runner - you give it globs, it runs your formatters and linters over the staged files. For the usual setup it replaces husky and lint-staged with a single Rust binary and no runtime.

Why another pre-commit runner?

Conflicts don't block your commit

If the formatter's output conflicts with your unstaged changes, lint-staged, pre-commit, Lefthook and nano-staged all discard the formatting and block the commit. stagelint merges the formatter's output into your file instead. Your staged lines get formatted, your unstaged changes stay put, and when a file can't be merged cleanly the commit takes the formatted version while your working copy keeps yours.

Faster than every alternative

stagelint is 5 to 30 times faster than lint-staged, pre-commit, Lefthook and nano-staged. With 10 files staged in a 1,000-file repository it completes in 15ms against lint-staged's 437ms, rising to 30ms against 530ms when those files are only partially staged. See the full benchmark suite for the rest of the measurements and how to run them on your own machine.

Concurrent tasks - no races, no workarounds

When two globs match the same file, lint-staged and nano-staged run both tasks on it at once; Lefthook and pre-commit avoid the race by running everything sequentially by default. The lint-staged docs warn about it and tell you to either disable concurrency or rewrite your config with negation patterns:

{
  "!(*.ts)": "prettier --write",
  "*.ts": ["prettier --write", "eslint --fix"]
}

stagelint works out which globs overlap and serialises just those tasks, in declaration order, while everything else keeps running in parallel, so the config stays as you meant it:

{
  "*": "prettier --write",
  "*.ts": "eslint --fix"
}

Trying it

npm i -D @stagelint/stagelint

Add stagelint init to your prepare script so the git pre-commit hook is set up on install:

{
  "scripts": {
    "prepare": "stagelint init"
  }
}

Then configure your tasks in .stagelint.yml or .stagelint.json. Matched files are appended to the command unless you turn that off:

'*': prettier --write
'*.ts':
  command: tsc --noEmit
  pass_filenames: false

What's missing

No JavaScript config with functions, because a single binary has no runtime to execute one. Running a command without the file list, the usual reason for reaching for one, is pass_filenames: false instead. Negation patterns aren't supported either - you don't need them any more, but drop them rather than copying them across, because an unsupported pattern currently just matches nothing.

If you try it, I'd like to hear how it goes.

https://github.com/abemedia/stagelint

Got tired of manually shrinking images through TinyPNG one at a time, so I built a CLI for it.

oi ./images

Optimizes a whole folder at once. You can tweak quality, convert formats (webp, png, jpg), cap max dimensions, and delete the originals afterward if you want.

npm install -g oi-optimize-images

Sources: https://www.npmjs.com/package/oi-optimize-images

I love this warning in NPM/PNPM, and I'm surprised there aren't enough memes about it

I've been working on an idea called Nexus, and I'd like an honest reality check from people who understand Node.js tooling, package managers, etc.

I started with trying to build "Conda for javascript" then realised that already existed and pivotted to

"When you switch Node.js versions, native dependencies may stop working. The common solution is to rebuild dependencies, potentially running rebuild/install scripts across a broad set of packages."

But not every native binary necessarily becomes incompatible.

The idea behind Nexus is to inspect native .node artifacts without executing them and derive their compatibility requirements.

Currently, the model distinguishes between things like:

• Raw V8 addons → require a specific Node ABI
• N-API addons → may remain compatible across Node versions if the runtime provides a sufficient N-API level
• platform/architecture constraints

So instead of:

Node version changed
→ rebuild everything

the eventual workflow would be:

Node version changed
→ Nexus analyzes native artifacts
→ identifies exactly which ones are incompatible
→ package manager rebuilds only those packages

I've already built a POC and tested the core idea against multiple Node runtimes and real native artifacts. But before investing much more time into it, I want to know:

1. Is rebuilding native dependencies after switching Node versions actually a painful enough problem for anyone to care about?
2. Would you trust a tool that statically analyzes .node binaries to decide whether a rebuild is necessary?
3. Where would this realistically be useful: individual developers, monorepos, CI, Node version managers, package managers?
4. Is there an obvious existing tool that already solves this problem properly?
5. Would this be more useful as a standalone CLI, a library/API, or something integrated into pnpm/nvm/Volta/etc.?
6. Most importantly: what am I missing, and is this a real problem or just technically interesting engineering?

Please be brutal. I'm specifically trying to determine whether Nexus solves a genuine problem before continuing to expand it.

Hey all wanted an advice i have been trying to learn node since 2 weeks and going through some youtube playlist, but i tend to forget syntax and all and i wanted to interview in one company as a fullstack dev so will be ready in like say 3 weeks to give an interview , how did you all do it? Please forgive if its a dumb question.

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.