MikroORM 7.2 is out — the second minor on top of v7.

New features:

• Row level security — PostgreSQL policies as entity metadata, created and diffed by the schema generator, with per-request session context pushed down to the connection; an existing @Filter can compile into a policy, so one declaration enforces at both layers
• through option for to-one relations — resolve a M:1 / 1:1 via a correlated subquery on a pivot entity, or pick a single row out of a to-many relation (e.g. the latest one) without loading the collection
• sql.js driver — SQLite compiled to WebAssembly, in memory, in the browser, Node.js, Bun and Deno with no native bindings. It also powers the new live playground in the getting-started guide, so the code in the docs runs against a real database as you read it
• Cursor pagination rework — a new optional Type.fromJSON() lets a custom type own its cursor wire format (sub-millisecond precision survives), and nullable sort keys now make the emitted order by and the keyset condition agree on where nulls sit
• Named parameters in em.execute() — :name for values, :name: for identifiers, as an alternative to the positional array
• String normalization — opt-in trim and casing on StringType / TextType, applied on writes and query parameters
• getNativeClient() — reach the underlying client for vendor APIs the ORM doesn't wrap: pg Pool, mysql2 Pool, better-sqlite3 / libsql Database, the PGlite instance, MongoClient
• await using support — the ORM instance implements Symbol.asyncDispose, so the connection closes with the enclosing scope
• index option on M:N properties — index the generated pivot table's join columns, which had no override on PostgreSQL before
• Nub TypeScript loader for the CLI, selected explicitly via tsLoader
• em.map() can bypass the identity map — map raw rows to entities without touching the current context
• Per-instance options callback for RequestContext.create() — different fork options per ORM instance
• migrations.snapshotOnMigrate — keep the snapshot managed solely by migration:create instead of rewriting it from the database on migrate
• CLI -q to suppress informational output, and cache:generate --combined now takes a path

Full blog post: https://mikro-orm.io/blog/mikro-orm-7-2-released
Changelog: https://github.com/mikro-orm/mikro-orm/releases/tag/v7.2.0

Happy to answer any questions!

Wanted to share commands instantly with a colleague without losing any encoding so I created this tool, Check it out here https://github.com/darula-hpp/cmdrop

I've recently discovered Tauri and built a project using React which if I run it purely from the terminal it opens up fine, but if I close the terminal and open Visual Studio, open the terminal in VS and run the same thing from the same place I get a Node.js error

In terminal both work correctly:

C:\Users\me\Documents\Tauri_test\react-test> npm run tauri dev (opens the app standalone)
or
C:\Users\me\Documents\Tauri_test\react-test> npm run dev (opens the app in browser)

In Visual Studio running the same lines I get the following:

Node.js v24.20.0
    Error The "beforeDevCommand" terminated with a non-zero status code

I've installed Node from the website and made sure it was added to Visual Studio on install, I've checked that VS can access Node from the 'react-test' folder, I've closed all other open apps in case something is clashing, I get the feeling that something is initialising in the wrong order and that's throwing Node off, but why would it work correctly outside of VS?

(If it doesn't cause issues I'll crosspost this as I don't know which bit of the system is causing the problem)

Solution:

IT WAS THE SODDING VISUAL STUDIO INDEXING

The .vs folder clogs up the system, here's how to get rid of it

Built an open source crawler that tracks tooling adoption in public TS/JS repos daily (methodology here). Drizzle currently leads the ORM category over Prisma, which surprised me given how dominant Prisma's mindshare has felt for the past few years.

Drizzle

Prisma

Is it the lighter runtime/no-codegen approach, edge/serverless compatibility, or something else?

Repo + daily-updated dataset if you want to dig into the numbers yourself or track other ORMs:

GitHub repo

I've used Prisma for years in production and, until now, it was one of those technology choices I basically didn't have to think about.

I genuinely liked Prisma 4/5/6/7: the schema, generated client, relation handling, implicit many-to-many, migrations, and especially the fact that after years of change requests I had a very understandable migration history.

I'm now about to start a new production backend that will probably live for many years: Node/TypeScript, Express, PostgreSQL, Redis, workers, etc.

Normally I would have picked Prisma without even having this discussion.

Then Prisma 8 happened.

I understand the technical argument for rewriting the internals, moving to TS, improving extensibility, etc.

My concern isn't really "I don't like the new syntax."

It's that Prisma 8 feels like a different product architecture, while at the same time Prisma as a company is increasingly selling the surrounding platform: Prisma Postgres, Prisma Compute, etc.

The migration change in particular makes me nervous. In the Prisma I know, I could look at the SQL migration and ultimately PostgreSQL was still the thing I owned. Prisma 8 moves toward contracts + migration.ts + compiled ops.json, with Prisma's migration runtime owning more of that lifecycle.

I'm not claiming Prisma is intentionally making self-hosted Postgres worse so they can sell Prisma Postgres. I have no evidence of that.

What worries me is simply incentives.

If the company monetizes the database, compute and surrounding infrastructure, there is now a natural incentive for the best/easiest Prisma experience to increasingly be:

Prisma ORM -> Prisma Postgres -> Prisma Compute -> Prisma everything

rather than:

Prisma ORM -> my PostgreSQL -> my infrastructure

I've been burned before by open-source dependencies changing licensing/distribution after years of use, so for a production dependency I now care a lot more about escape hatches and who owns each layer.

This is why I'm suddenly seriously evaluating Drizzle/Kysely. Not because "Reddit says Prisma bad", but because SQL migrations and a thinner abstraction mean that if the ORM disappears or changes direction, PostgreSQL is still PostgreSQL.

For people actually running these things in production:

Would you start a new multi-year project on Prisma 8 today?

Would you pin Prisma 7 and keep using the old architecture?

Did you move from Prisma to Drizzle/Kysely, and do you miss Prisma's higher-level relation/query API?

Do you think I'm reading too much into Prisma's business direction?

Is there something about the Prisma 8 migration/contract architecture that makes it better for a long-lived production system that I'm missing?

I'm particularly interested in answers from people maintaining systems with years of migrations and changing requirements, rather than which ORM feels nicest in a weekend project.

Edit: tested drizzle in a side project , simulating as if I received change requests I know happen in real products . And I like the migration system and I like the simple crud cake they are already proving, and the control you have over more complex query since some db service charge you per operation rather then compute, so you can even optimize query per cost. That's it drizzle is my new home.

i am doing some exercises on my laptop running cachyos kde

so i will be doing exercises and each exercises sometimes have different app. all do use the same way to dependencies. is there a way to maybe just for these group of exercises i want them to share one node module folder where the package and dependencies reside. i know about global but i dont want to use that.

whats my alternative for playwrights browser if i dont want google invading my privacy

termdom.org

Hey guys,

I just published use-courier, a headless React hook for handling file uploads. I originally built it for a personal project, but ended up turning it into a standalone package in case it could be useful to anyone else.

It handles some of the stuff I found myself repeatedly having to build around file uploads:

• Real upload progress tracking
• Upload cancellation
• Chunked uploads for large files
• Multiple concurrent uploads
• Headless, so you're free to build whatever UI you want around it

The goal was to make the upload logic easy to drop into an application without forcing a particular UI or component library.

NPM: https://www.npmjs.com/package/use-courier

docs: https://mrphilipp7.github.io/useCourier/

I'd really appreciate any feedback, especially around the API design, implementation, documentation, or anything you think could be improved. It's still new, so I'm very open to criticism.

I recently took on a coding challenge to build an end-to-end documentation assistant using RAG.

Instead of just making something that "works", the challenge pushed me to think about what happens underneath a production-ready RAG system.

I built a documentation assistant that:

- ingests and chunks documentation

- generates embeddings and stores them in Redis

- retrieves relevant context for each question

- generates grounded answers using an LLM

- uses semantic caching to avoid unnecessary LLM calls

- maintains session memory

- streams responses using SSE

The most interesting part for me wasn't getting the RAG pipeline working. It was thinking about the problems around it:

How similar does a query need to be before we can reuse a cached answer?

What information should actually be stored as memory?

How do you keep retrieval relevant as the amount of documentation grows?

And how do you design the system so that you're not blindly sending every request to an LLM?

It was a great exercise in going beyond "LLM + vector database" and thinking about the system as a whole.

I ended up building it with React, vite, nest, postgres, redis, and ts.

Still plenty I'd improve, but I'm happy with where it ended up.

https://github.com/Ramzi-Abidi/RTFM

If you're working with RAG or ai applications, I'd be interested to hear how you'd approach the caching and memory parts.

Hey r/node,

I've been working on Oasis Editor, an open-source TypeScript document editor published as an npm package.

It includes:

• a custom Canvas-based rendering engine
• paged document layout
• typed command/plugin APIs
• vanilla JS integration
• React and Vue adapters
• a headless runtime
• DOCX/PDF workflows

Install:

npm install oasis-editor

Live playground:
https://celsowm.github.io/oasis-editor/#/editor

GitHub:
https://github.com/celsowm/oasis-editor

I'd love feedback on the package API, exports, and overall developer experience.

Am I the only one who had a problem with how separated the data manipulation is?

Creating something in different ways (eg. create a chat message from only a text or creating from an api response ) Defaults in 3 files, parsing, validation, and sorting everything inline just to search it up later and copy it.

My solution? Put stuff like that in one place: ^{See the screenshots.}

Basically define all that sh in one place and just use:

userModel.parser.db.from(response)

habitModel.inits.createFromTitle("Do a blackflip")

people.sort(peopleModel.sorters.lastCreated)

https://github.com/dozsolti/manage-model

Hello!

After COVID hit, I was stuck at home and ended up doing some consultancy work for a high-paced operations setup in my hometown. Users needed to be matched with assignments based on their skills and competencies and then complete those assignments. One of the things I battled with was volume, we needed to ingest and distribute at times 1000+ tasks per second to 150+ employees. It wasn't actually as easy I first thought.

The main challenge was the latency of assignment distribution, combined with the requirement that everything had to remain on-premises. So, I built a solution for it, back in the day with postgres as that was what we used . In retrospective it was a mistake.

After changing jobs, I open-sourced the v2 of library and idea but never really published or promoted it anywhere. With the help of AI and extensive testing, I’ve finally brought the project to a state where I believe it can help others avoid many of the problems I faced while scaling it—especially as the requirements for flexibility and configurability skyrocketed.

I'd really appreciate a ⭐ but also comments and feedback is much welcome. It should be really LLM / vibes friendly so I think anyone could basically set it up if really needed.

repo: https://github.com/ViljarVoidula/assignment-user-matcher

npm: https://npmjs.com/package/assignment-user-matcher

I work on it after hours so please be patient with requests if having any.

So I built my first project with Astro, I run "pnpm install" then run and then build generated the dist folder. I would like to publish this sample static site to netlify via github...I did everything in my local laptop (Fedora 44) how can I push my dist folder to github now? Or should I follow other paths, idk pushing the entire project folder to github and not only the dist folder?. I know netlify support a local folder upload but I would like to understand how to use github in this process and so link netlify to github

thanks

Keyword frequencies taken from https://www.zoevera.com/resume/software-engineer-job-description-keywords

Most software engineer keyword lists are assembled from experience or guesswork. This one is a count: every open posting from 72 companies' public Greenhouse job boards, filtered to the 1,360 whose title contains "software engineer", then checked for how many mention each of 45 terms at least once.

The percentage beside each term is the share of those 1,360 postings that mention it.

PRACTICES AND WAYS OF WORKING

Scalability 52.9% - Mentoring 47.4% - Distributed systems 47% - System design / architecture 46.7% - Cross-functional 31% - Code review 27.2% - On-call 20.7% - CI/CD 19.5% - Agile / Scrum 9.3% - Unit / automated testing 6.5%

This is the result I did not expect. The four most common terms in the whole study are not technologies. Scalability, mentoring, distributed systems and system design all appear in more postings than Python does. Nearly half of these postings mention mentoring, and almost no engineer resume I have seen makes a claim about it.

Agile and Scrum at 9.3% is the other surprise, given how much resume advice insists on them.

LANGUAGES

Python 44.8% - Java 35.4% - Go 31.1% - TypeScript 19.8% - C++ 17.4% - SQL 17.3% - JavaScript 13.2% - Kotlin 12% - Rust 9.9% - Scala 8.6% - Ruby 8.5% - C# 5.3% - Swift 2.3%

TypeScript at 19.8% against JavaScript at 13.2% is a real ordering, not noise. The gap is wider than both margins of error combined.

CLOUD AND INFRASTRUCTURE

AWS 41.3% - Kubernetes 30.9% - GCP 19.3% - Azure 17.6% - Terraform 13.2% - Docker 12.6% - Microservices 7.1% - Linux 4.8%

AWS appears in more than twice as many postings as GCP and Azure individually. Kubernetes at 30.9% outranks every language except Python, Java and Go.

FRONTEND AND APIs

React 21.1% - REST / RESTful 9.6% - GraphQL 6% - Node.js 5.5% - Vue 3.2% - Angular 2.9%

Frontend framework lists usually present React, Vue and Angular as three comparable options. In this corpus React appears in roughly seven times as many postings as Vue and Angular combined.

DATA STORES AND PIPELINES

PostgreSQL 14.3% - Kafka 13.1% - MySQL 11.3% - Spark 9.8% - MongoDB 7.4% - Redis 7.4% - Elasticsearch 6.4% - Snowflake 5.6%

WHAT THIS SAMPLE IS NOT

These are 72 technology companies hiring through Greenhouse. Agencies, consultancies, banks, defense contractors and the public sector are absent, and their vocabulary is different - COBOL, .NET, SAP, clearance requirements and named compliance regimes barely register here and may dominate elsewhere.

The title filter is "software engineer" only. Postings titled backend engineer, frontend engineer, full stack developer, SRE or platform engineer were not counted, so this describes the generalist title rather than the whole profession.

Absence in this list is not evidence of absence in the market. Only 45 terms were counted. Next.js, Svelte, Django, Spring Boot, gRPC, Jest, Playwright, Datadog, OpenTelemetry and OAuth were never checked, so nothing here says anything about them either way.

It is a snapshot of open roles on one date rather than a trend, and the corpus is US-skewed.

One thing this sample size does buy: at n=1,360 the margins of error are roughly plus or minus 2 to 3 points, so most of the ordering above is real. Gaps under about 5 points are still worth treating as ties - React at 21.1% and TypeScript at 19.8% is not a meaningful difference.

METHOD

Greenhouse's public job board API, the endpoint companies expose so their listings can be embedded on their own sites. No scraping. Counts are document frequency: a posting saying "Python" nine times counts once. Deduped on company, title and content length, because one role posted to five offices returns five near-identical records. Median posting length is 896 words.

Ambiguous words are matched case-sensitively with exclusions, which matters more here than you would think. A bare word-boundary match on "Go" also catches "go to market" and "go above and beyond", which inflated Go by about two points before it was fixed. React, Spark, Swift and Rust all have the same problem.

Full table with all 45 terms and confidence intervals:

https://www.zoevera.com/resume/software-engineer-job-description-keywords

The wider keyword list this was checked against, organized by language, framework and platform:

https://www.zoevera.com/resume/ats-resume-tips-software-engineer

Happy to run the numbers on any terms missing from the list if people name them in the comments.

Hey r/node,

I've been working on Oasis Editor, an open-source document editor written in TypeScript.

Besides the browser UI and Canvas-based rendering engine, it also exposes a headless runtime and a typed command/plugin API, so the document model and editor logic aren't tied only to the visual shell.

It ships as an npm package with vanilla JS, React and Vue integrations, plus DOCX/PDF workflows.

Live playground:
https://celsowm.github.io/oasis-editor/#/editor

GitHub:
https://github.com/celsowm/oasis-editor

I'd love feedback on the package architecture, headless runtime, and API design.

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?