r/nestjs

My theory is that if the framework has more rules, the AI will make fewer mistakes, allowing me to focus on the actual product

to those who have made the switch: did you find that a more structured framework improved your AI workflow and reduced technical debt?

I have implemented an EDI (for invoicing) system from scratch in Node.js/ NestJs and integrated it into our enterprise-grade system. I wonder if there is a job market for this to work as a software engineer specialized in the development of EDIFACT systems for enterprise-grade systems. I know that there are a lot of tools to build and map the EDI data fields, but I am not speaking of using these vendor tools like IBM Sterling; I am exclusively referring to implementing the EDIFACT standards from scratch, the EDI file generation, validation, and parsing. Is this a thing? I couldn't even find any libraries to help me generate or parse the EDI files in Node.js, so I had to implement everything from scratch.

I'm stuck trying to get a clean dev setup for a Turborepo + pnpm monorepo. I have a NestJS app at `apps/api` and many packages in `packages/` The API depends on it.

For context im migrating from nextJS to nest.

I need **all four of these at once** and can't find a setup that satisfies everything:

1. No pre-build — I don't want to run `turbo build --filter=@repo/package` before starting the API. Changes in `@repo/package/src` should be reflected immediately.
2. Works in Docker — The dev container starts fresh with no `dist/` folders (gitignored). Any setup that relies on `dist/` existing fails.
3. NestJS DI works correctly — `@Injectable()`, `@Controller()`, etc. must emit decorator metadata (`emitDecoratorMetadata: true`). Using `tsx` directly breaks this, causing injected services to be `undefined` at runtime.
4. Watch mode — Changes in both `apps/api/src` AND `@repo/packages/src` should hot-reload the server.

What I've tried:

- `tsx --conditions=development --watch ./src/main.ts` → breaks NestJS DI.

- `nest start --watch` with `NODE_OPTIONS=--conditions=development` → can't import `.ts` files directly, doesn't watch workspace package changes

all my packages exports use a `development` condition pointing to `./src/*.ts` and `production`/`default` pointing to `./dist/*.mjs`.

What's the correct dev setup here? Has anyone solved this combination cleanly?

Hey everyone! I just published vite-plugin-nestjs: a Vite plugin that replaces the NestJS CLI as your dev/build tool.

Why?

The NestJS CLI uses its own compiler pipeline (ts-jest, SWC, etc.), which means you're locked out of the Vite plugin ecosystem. I wanted to use Vite plugins in a NestJS project and couldn't find a clean way to do it, so I built one.

What it does:

• Runs your NestJS app through Vite's dev server, your controllers are available at localhost:5173 with full Vite support
• Gives you access to the entire Vite plugin ecosystem in your backend project
• Automatically detects @nestjs/swagger in your nest-cli.json and generates Swagger metadata before any request is handled, no manual step required
• vite build bundles your Nest app as an SSR Node.js module you can run with node dist/main.js
• npm: https://www.npmjs.com/package/vite-plugin-nestjs
• GitHub: https://github.com/Alan-Gomes/vite-plugin-nestjs

Would love feedback, bug reports, or ideas. Happy to answer any questions!

I have a pnpm monorepo with two apps a NestJS API and a Node.js scraper both using Prisma 7. I want a single PrismaClient instance defined in a shared /myapp/database package so both apps use the same configuration and connection setup.

#folder structure
apps/
  api/          # NestJS app
  node-app/      
packages/
  database/
    src/
      generated/prisma/   
      index.ts            # exports prisma instance + types
    prisma/
      schema.prisma
    package.json
package.json

#packages/database/src/index.ts:
 
import { PrismaPg } from '@prisma/adapter-pg';
import { PrismaClient } from './generated/prisma/client.js';

const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL! });

export const prisma = new PrismaClient({ adapter });

export * from './generated/prisma/client.js';
, 

The nodejs app imports it directly, no issues. The problem is NestJS the standard pattern is to extend PrismaClient in an Injectable() service, which creates a second instance alongside the one already created in the shared package.

is it actually a problem to have two separate PrismaClient instances here (one per app process)? Since the scraper and API run as separate processes If it is a problem, how do I wrap the existing singleton so NestJS's DI system uses it without creating a new one?

Injectable()
export class PrismaService {
  // somehow wrap/expose the shared singleton here
}

Also, please don’t say “ask AI.” I did, and I’m not sure about its answers. I don’t want to blindly follow it, as this is a strictly no-AI project to improve my knowledge since I’m still a junior developer.

I am looking for a library that doens't require me to chunk my file buffers prior to upload my files , things like support downloads in separate processes . any guesses ?

Hey r/nestjs 👋

I've been building omnichannel chat platforms for 5+ years and one thing I always had to implement from scratch on every project was user presence tracking — who's online, who's offline, which agents are available in a room.

There was no dedicated npm package for this in the NestJS ecosystem. So I built one.

---

**nestjs-socket-presence** — https://www.npmjs.com/package/nestjs-socket-presence

Install:

npm install nestjs-socket-presence ioredis

---

**What it does:**

- Automatic online/offline tracking on socket connect/disconnect

- Multi-socket per user (one user, multiple tabs/devices — single presence state)

- Redis TTL expiry — ungraceful disconnects auto-expire (no ghost users ever)

- Heartbeat support — clients refresh TTL on a timer

- Room presence — who's online in a specific room right now

- Bulk presence queries — check hundreds of users in one Redis round-trip

- Multi-instance safe — works behind a load balancer

- register() and registerAsync() — works with ConfigService

---

**Usage is dead simple:**

// app.module.ts

PresenceModule.register({

redis: { host: 'localhost', port: 6379 },

ttl: 30,

})

// Client

const socket = io('http://localhost:3000', {

auth: { userId: 'user-123' }

})

// That's it. User is now tracked as online.

// Inject PresenceService anywhere

const online = await this.presenceService.isOnline('user-123');

const room = await this.presenceService.getRoomPresence('support-room');

const bulk = await this.presenceService.getBulkPresence(['u1', 'u2', 'u3']);

---

**Why Redis?**

So it works across horizontally scaled NestJS pods. One user connects to pod A, another to pod B — presence state is shared via Redis. No ghost users, no split-brain.

---

GitHub: https://github.com/SaifuddinTipu/nestjs-socket-presence

npm: https://www.npmjs.com/package/nestjs-socket-presence

22 unit tests. Full TypeScript types. MIT license.

Feedback and PRs very welcome — this is v1.0.0 and I want to make it production-solid.

I have deployed my app on gcp's cloud function , and each cold start of the app is quite costly , has anyone tried to improve theirs ? i'ld love some suggestions .